My bundle depends on an rdf4j bundle which has to use Guava 18.0, and it
also depends on a bundle that has to use Guava 20.0.  I have it set to
Guava 20.0 in my rkmoquin common bundle.  I am actually trying to install
an overall feature which includes some other features.  It had been working
fine until I added Jclouds to the mix which I think uses a version range
for Guava.  I guess this is because I have a feature which depends on two
other features which each depend on different versions of Guava.  The main
bundle for my feature also uses Guava as a dependency but specifies and
installs a certain version of it.  It seems like even if my bundle
specifies a certain version of Guava, because other classes used in that
bundle "uses" classes that could bind to other Guava versions, then the
class space can't be guaranteed to be the same version of Guava
dependencies (if that makes any sense)?

I don't think my bundle has to use Guava 20.0, it was the best version to
depend on that didn't result in uses constraints with other bundle
dependencies previously.  Adding JClouds with it's Guava dependency range
maybe causes uncertainty in the class space?  So guess there could be a mix
of packages which are in the same class path but "uses" different versions
of a package.

I can't do a refresh since the feature install fails and then the problem
bundle isn't installed...I guess if I manually install the dependencies, I
can then use Karaf to see how it is trying to wire then.  I would think
this is where making certain dependant features a "prerequisite" might help
with that, but doing that seems to cause things to go crazy when I try that
:). I don't think I understand the prerequisite and dependency attributes
for features.

Ryan



On Fri, Jan 26, 2018 at 10:15 AM Jean-Baptiste Onofré <[email protected]>
wrote:

> Hi Ryan,
>
> can you try a refresh ?
>
> What's your import in the rkmoquin.common bundle ?
>
> Regards
> JB
>
> On 01/26/2018 03:40 PM, Ryan Moquin wrote:
> > I keep running into situations where I get a uses constraint, but the
> complaint
> > is talking about an import and export chain that involve the exact same
> > dependency, such as with Guava below... why is this a uses constraint
> and how do
> > you deal with it?
> >
> > Error executing command: Uses constraint violation. Unable to resolve
> resource
> > com.rkmoquin.common [com.rkmoquin.common/1.0.0.SNAPSHOT] because it is
> exposed
> > to package 'com.google.common.base' from resources com.google.guava
> > [com.google.guava/20.0.0] and com.google.guava [com.google.guava/20.0.0]
> via two
> > dependency chains.
> >
> > Chain 1:
> >   com.rkmoquin.common [com.rkmoquin.common/1.0.0.SNAPSHOT]
> >     import:
> >
> (&(osgi.wiring.package=com.google.common.base)(version>=20.0.0)(!(version>=21.0.0)))
> >      |
> >     export: osgi.wiring.package: com.google.common.base
> >   com.google.guava [com.google.guava/20.0.0]
> >
> > Chain 2:
> >   com.rkmoquin.common [com.rkmoquin.common/1.0.0.SNAPSHOT]
> >     import:
> >
> (&(osgi.wiring.package=com.google.common.collect)(version>=20.0.0)(!(version>=21.0.0)))
> >      |
> >     export: osgi.wiring.package: com.google.common.collect;
> > uses:=com.google.common.base
> >     export: osgi.wiring.package=com.google.common.base
> >   com.google.guava [com.google.guava/20.0.0]
> >
> > Thanks for any help!
> > Ryan
>
> --
> Jean-Baptiste Onofré
> [email protected]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Reply via email to