Hi Ryan,

Can you share your pom.xml and your feature.xml ?

François


Le 26/01/2018 à 20:55, Ryan Moquin a écrit :
> 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]
> <mailto:[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.
>     <http://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.
>     <http://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.
>     <http://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] <mailto:[email protected]>
>     http://blog.nanthrax.net
>     Talend - http://www.talend.com
>

Reply via email to