You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Ryan Moquin <fr...@gmail.com> on 2018/01/26 14:40:05 UTC
Why does Karaf say this is a uses constraint?
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
Re: Why does Karaf say this is a uses constraint?
Posted by Tim Ward <ti...@paremus.com>.
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 <fr...@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 <fr...@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é <jb...@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é
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>
Re: Why does Karaf say this is a uses constraint?
Posted by Ryan Moquin <fr...@gmail.com>.
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.papon@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é <jb...@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é
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
Re: Why does Karaf say this is a uses constraint?
Posted by Francois Papon <fr...@openobject.fr>.
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é <jb@nanthrax.net
> <ma...@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.
> <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é
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Why does Karaf say this is a uses constraint?
Posted by Ryan Moquin <fr...@gmail.com>.
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é <jb...@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Why does Karaf say this is a uses constraint?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Why does Karaf say this is a uses constraint?
Posted by Ryan Moquin <fr...@gmail.com>.
BTW - I'm using Karaf 4.1.4 when I get this...
Thanks,
Ryan
On Fri, Jan 26, 2018 at 9:40 AM Ryan Moquin <fr...@gmail.com> 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
>