Francois, JB: I figured it out shortly after writing this email. This issue was caused by a combination of a small goof on my side and a misconception on what version of Guava is supported by JClouds. My goof was that I forgot that in order to programmatically work with JClouds, I had to use a couple Guava classes since JClouds heavily uses it. As a result of that, my library had an import statement in it's bundle that I forgot about (I was trying to not have to use any Guava stuff, and forgot I couldn't get around it a few days previously). The other part of this was that I thought JClouds had 18.0 - 20.0 set as the valid ranges for Guava, but it's actually 16.0 - 19.0 but since I had 20.0 as the default version in dependency management in my POM, my bundle using JClouds was expecting 20.0 as the only valid version, but JClouds won't wire to that version, hence the error message. Unfortunately these uses constraint violation errors are very unclear in the majority of cases. Since this was really about Guava 20.0 being imported by my bundle and JClouds binding to a version 19.0 or below.
On Fri, Jan 26, 2018 at 12:35 PM Francois Papon < [email protected]> wrote: > 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]> > 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 >> > >
