The bndtools Eclipse plugin consistently reports a 'uses constraint violation' for logback that I just have not been able to track down (I've been through every related question that I can find on StackOverflow and Google).
The constraint violation shows up every time I modify a 'run configuration' and eventually disappears after enough project clean/rebuilds and Eclipse restarts (the muttered invocations to sundry gods and occasional chicken sacrifice may also have something to do with it).
Nothing in my workspace seems to export logback directly so it's not clear what is causing the two conflicting chains - it may be one of the Felix bundles or SLF4J, but that also seems unlikely.
Partial list of bundles:
osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\
osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)',\
osgi.identity;filter:='(osgi.identity=org.apache.felix.log)',\
osgi.identity;filter:='(osgi.identity=slf4j.api)',\
osgi.identity;filter:='(osgi.identity=ch.qos.logback.core)',\
osgi.identity;filter:='(osgi.identity=ch.qos.logback.classic)',\
The constraint violation report:
Uses constraint violation. Unable to resolve resource ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2] because it is exposed to package 'ch.qos.logback.classic.spi' from resources ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2] and ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2] via two dependency chains.
Chain 1: ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2]
import: (&(osgi.wiring.package=ch.qos.logback.classic.spi)(version>=1.1.0))
|
export: osgi.wiring.package: ch.qos.logback.classic.spi ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2]
Chain 2: ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2]
import: (&(osgi.wiring.package=ch.qos.logback.classic.spi)(version>=1.1.0)(!(version>=2.0.0)))
|
export: osgi.wiring.package: ch.qos.logback.classic.spi ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2] org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2] because it is exposed to package 'ch.qos.logback.classic.spi' from resources ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2] and ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2] via two dependency chains.
Chain 1: ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2]
import: (&(osgi.wiring.package=ch.qos.logback.classic.spi)(version>=1.1.0))
|
export: osgi.wiring.package: ch.qos.logback.classic.spi ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2]
Chain 2: ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2]
import: (&(osgi.wiring.package=ch.qos.logback.classic.spi)(version>=1.1.0)(!(version>=2.0.0)))
|
export: osgi.wiring.package: ch.qos.logback.classic.spi ch.qos.logback.classic [ch.qos.logback.classic ver=1.1.2] at org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1133) at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1086) at org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1402) at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1086) at org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1402) at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1086) at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:260) at biz.aQute.resolve.ResolveProcess.resolveRequired(ResolveProcess.java:34) at org.bndtools.core.resolve.ResolveOperation.run(ResolveOperation.java:61) at org.bndtools.core.resolve.ResolveJob.run(ResolveJob.java:43) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Is there a way to troubleshoot this ? I'd even be really happy for just a consistent workaround ..
Related
2.8 together with its cxf feature 3.3.5, with cxf-jaxrs which is installed as feature comes a dependency to Google Guava 20.0. I have my own project where I install a couple of jars via Karaf feature, among them a Google Guava 18.0. The bundle I want now to install has a Google Guava dependency for 18.0, however i get the following error:
Chain 1:
arcanite-core [arcanite-core [269](R 269.0)]
import: (&(osgi.wiring.package=com.google.common.collect)(version>=18.0.0)(!(version>=19.0.0)))
|
export: osgi.wiring.package: com.google.common.collect
com.google.guava [com.google.guava [253](R 253.0)]
Chain 2:
arcanite-core [arcanite-core [269](R 269.0)]
import: (&(osgi.wiring.package=com.querydsl.core)(version>=4.2.0)(!(version>=5.0.0)))
|
export: osgi.wiring.package=com.querydsl.core; uses:=com.google.common.collect
com.querydsl.core [com.querydsl.core [255](R 255.0)]
import: (&(osgi.wiring.package=com.google.common.collect)(version>=18.0.0))
|
export: osgi.wiring.package: com.google.common.collect
com.google.guava [com.google.guava [172](R 172.0)] Unresolved requirements: [[arcanite-core [269](R 269.0)] osgi.wiring.package; (&(osgi.wiring.package=com.querydsl.core)(version>=4.2.0)(!(version>=5.0.0)))]
In my imports for the project I have explicitly imported the 18.0 version:
<Import-Package>
...
com.google.common.collect;version="[18.0,19.0)",
*
<Import-Package>
How can I get rid of this conflict, is this really about having only one version of Guava in Karaf ( OSGI ), what am i doing wrong?
Ok that was a tricky one, as said the cxf-feature made up a dependecy to Guava 20.0.
Then installing my own feature with query-dsl and guvava 18.0 jar inside.
But the dependency querydsl to guava was not resolved according to maven, but according to the already existing guava in karaf so 20.0.
When i now install a bundle with query-dsl and guava 18.0 then there is the conflict.
In the end i removed 18.0 library from the feature and allowed a larger version range in my project:
...
com.google.common.collect;version="[18.0,23.0)",
*
And the conflict was gone, makes me wonder how would i specify such a dependency, here between querydsl and guava 18.0 in the feature.xml, if possible at all.
I work on a multi module maven project with osgi bundles deployed to karaf. We are observing intermittent bundle start-up issues in our test and production environments due to the below error, which is later resolved after restarting the karaf container:
Caused by: org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve resource myBundle [myBundle [16](R 16.0)] because it is exposed to package 'javax.el' from resources javax.el-api [javax.el-api [236](R 236.0)] and com.sun.el.javax.el [com.sun.el.javax.el [212](R 212.0)] via two dependency chains.
Chain 1:
myBundle [myBundle [16](R 16.0)]
import: (&(osgi.wiring.package=javax.el)(version>=3.0.0)(!(version>=4.0.0)))
|
export: osgi.wiring.package: javax.el
javax.el-api [javax.el-api [236](R 236.0)]
Chain 2:
myBundle [myBundle [16](R 16.0)]
import: (&(osgi.wiring.package=com.sun.el)(version>=3.0.0)(!(version>=4.0.0)))
|
export: osgi.wiring.package: com.sun.el; uses:=javax.el
export: osgi.wiring.package=javax.el
com.sun.el.javax.el [com.sun.el.javax.el [212](R 212.0)] Unresolved requirements: [[myBundle [16](R 16.0)] osgi.wiring.package; (&(osgi.wiring.package=com.sun.el)(version>=3.0.0)(!(version>=4.0.0)))]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[10:org.apache.karaf.features.core:4.0.7]
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[10:org.apache.karaf.features.core:4.0.7]
... 6 more
I went through these 2 related SO posts (Error starting bundle in karaf: "via two dependency chains" and Why are uses constraints violated when both chains end in the same bundle? ) but in my situation I am actually unable to determine where from the javax.el-api dependency is being introduced to myBundle. Our project uses Hibernate Validator, which requires the EL package from glassfish jar, so this is where the com.sun.el.javax.el package dependency is introduced. I was unable to determine where the javax.el-api dependency is being introduced from though. I tried checking the dependency tree using the below maven commands but to no avail.
mvn compile dependency:tree
mvn compile dependency:tree -D:verbose
mvn compile dependency:tree -D:verbose -Dincludes=javax.el
This is the dependency added for hibernate validator:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.el</artifactId>
<version>3.0.1-b08</version>
</dependency>
The karaf version being used is 4.0.7
Any help will be appreciated.
I'm fairly new to OSGi and I've run into what has to be a very simple, beginner's error.
When I added a BundleActivator to my Bundle, I get the following resolution error:
[INFO] Building jar: C:\projects\osgi.enroute-master\projects\testproject\app\target\app-0.0.1-SNAPSHOT.jar
[INFO]
[INFO] --- bnd-indexer-maven-plugin:4.0.0:index (index) # app ---
[INFO]
[INFO] --- bnd-indexer-maven-plugin:4.0.0:index (test-index) # app ---
[INFO]
[INFO] --- bnd-export-maven-plugin:4.0.0:export (default) # app ---
[ERROR] Resolution failed. Capabilities satisfying the following requirements could not be found:
[<<INITIAL>>]
? osgi.identity: (osgi.identity=org.foo.examples.service.impl)
? [org.foo.examples.service.impl version=0.0.1.201806070724]
? osgi.wiring.package: (&(osgi.wiring.package=org.osgi.framework)(&(version>=1.9.0)(!(version>=2.0.0))))
? [org.osgi.framework version=1.9.0.201802012106]
? osgi.wiring.package: (&(osgi.wiring.package=org.osgi.dto)(&(version>=1.1.0)(!(version>=2.0.0))))
The following requirements are optional:
[org.apache.felix.scr version=2.1.0]
? osgi.wiring.package: (&(osgi.wiring.package=org.osgi.service.cm)(&(version>=1.6.0)(!(version>=2.0.0))))
? osgi.wiring.package: (&(osgi.wiring.package=org.apache.felix.service.command)(&(version>=1.0.0)(!(version>=2.0.0))))
? osgi.wiring.package: (&(osgi.wiring.package=org.apache.felix.shell)(&(version>=1.0.0)(!(version>=1.1.0))))
? osgi.wiring.package: (&(osgi.wiring.package=org.osgi.service.log)(&(version>=1.3.0)(!(version>=2.0.0))))
? osgi.wiring.package: (&(osgi.wiring.package=org.osgi.service.metatype)(&(version>=1.2.0)(!(version>=2.0.0))))
I'm using the OSGi enRoute example on GitHub, which uses maven plugins and custom archetypes to setup the project and different kinds of bundles. It also uses the Bndtools which - as far as I understand - is supposed to automatically resolve exactly these kinds of bundle dependencies. I cannot rule out that underneath the OSGi dependency issue is a Maven dependency as well.
Is there any documentation on how to parse and understand this types of errors?
I know this question is vague, I currently lack the understanding to even precisely formulate the problem :)
For resolution errors you first look into the innermost resolution that fails. In your case it is:
osgi.wiring.package: (&(osgi.wiring.package=org.osgi.dto)(&(version>=1.1.0)(!(version>=2.0.0))))
This can be translated you are missing a bundle that provides an export of the package "org.osgi.dto" with a version of [1.1.0,2.0.0). This package is provided by
https://mvnrepository.com/artifact/org.osgi/org.osgi.dto
So you could try to install this bundle.
In what scenario, the following error could happen? This happens sporadically when starting an application with several bundles. What would be the fix for this error?
Caused by: org.osgi.framework.BundleException: Unable to resolve module com.springsource.slf4j.api [135.0] because it exports package 'org.slf4j.spi' and is also exposed to it from com.springsource.slf4j.api [135.0] via the following dependency chain:
com.springsource.slf4j.api [135.0]
import: (&(package=org.slf4j.impl)(version>=1.6.1)(!(version>=2.0.0)))
|
export: package=org.slf4j.impl; uses:=org.slf4j
com.springsource.slf4j.api [135.0]
import: (&(package=org.slf4j)(version>=1.6.1)(version<=1.6.1))
|
export: package=org.slf4j; uses:=org.slf4j.spi
com.springsource.slf4j.api [135.0]
import: (&(package=org.slf4j.spi)(version>=1.6.1)(version<=1.6.1))
|
export: package=org.slf4j.spi
com.springsource.slf4j.api [135.0]
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3574)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1619)
SLF4J is OSGi friendly since a while so there is no need to use springsource based jar-s.
Install the newest slf4j-api jar with the implementation you would like to use!
How it works:
slf4j-api uses classes that are not in the jar and they are not imported. slf4j-xxximpl (like slf4j-simple) are fragment bundles where the host is slf4j-api so they will have a common classloader.
This means that you have to install an slf4j-api and slf4j-xxx together (if you install it runtime call a refresh on the container if necessary to have good wirings). This also means that slf4j cannot work with more implementations and it is also not a good idea to have multiple versions of slf4j-api in the same container.
Solution: Remove the springsource based jar and install the newest slf4j-api and impl jars into the container and after that call refresh if necessary.
I am trying to create a new maven (3.0.3) plugin based on an existing (2.0) plugin, and facilitating aether to pickup some dependencies.
I tried to create a simple test to load the mojo using the maven-plugin-testing-harness (version 2.0.1), but lookupMojo fails with a guice exception:
1) Error injecting: org.sonatype.aether.impl.internal.DefaultRepositorySystem
at ClassRealm[plexus.core, parent: null]
at ClassRealm[plexus.core, parent: null]
while locating org.sonatype.aether.RepositorySystem
while locating org.codehaus.griffon.maven.plugin.MvnValidateMojo
at ClassRealm[plexus.core, parent: null]
while locating org.apache.maven.plugin.Mojo annotated with #com.google.inject.name.Named(value=org.codehaus.griffon:griffon-maven-plugin:1.3.0-SNAPSHOT:validate)
This of course is because I need to reference the repository system at some point, but not right now:
#Component
private RepositorySystem repoSystem;
I have tried (actually started with) version 2.1, but got the problem in the AbstractMojoTestCase#setUp() method.
org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException
role: org.apache.maven.repository.RepositorySystem
roleHint:
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:247)
Either way, Not sure what I need to include and where to do a vanilla mojo load test similar to the cookbook. Anybody got any ideas?
7 years later and I am hitting the same issue.
The solution is to also add the maven-compat artifact as test scoped dependency as the maven-plugin-testing-harness is apparently still relying on the old Maven 2 API.
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-compat</artifactId>
<version>[REQUIRED_MAVEN_VERSION_HERE]</version>
<scope>test</scope>
</dependency>
Kudos to user smoke for his answer here https://stackoverflow.com/a/16707144/5116073