Why does Karaf say this is a uses constraint?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Why does Karaf say this is a uses constraint?

rkmoquin
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
Reply | Threaded
Open this post in threaded view
|

Re: Why does Karaf say this is a uses constraint?

rkmoquin
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Why does Karaf say this is a uses constraint?

jbonofre
In reply to this post by rkmoquin
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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Why does Karaf say this is a uses constraint?

rkmoquin
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é <[hidden email]> 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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Why does Karaf say this is a uses constraint?

fpapon

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é <[hidden email]> 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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Francois Papon
Openrun : https://www.openrun.re
Reply | Threaded
Open this post in threaded view
|

Re: Why does Karaf say this is a uses constraint?

rkmoquin
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 <[hidden email]> 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é <[hidden email]> 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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Why does Karaf say this is a uses constraint?

Tim Ward-2
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 <[hidden email]> 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 <[hidden email]> 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é <[hidden email]> 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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com