The JClouds API sucks for this reason. They always return/receive a guava collection type rather than just using guava to generate the collections. It’s a leaky abstraction nightmare!
Tim Sent from my iPhone > On 29 Jan 2018, at 15:58, Ryan Moquin <fragility...@gmail.com> wrote: > > 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 >> <francois.pa...@openobject.fr> 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é <j...@nanthrax.net> >>>> 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é >>>> jbono...@apache.org >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>
