OSGi enRoute with Maven - dependencies resolution error

[Matteo Rulli]

Hello,

I tried to complicate a little bit the "Using OSGi enRoute with Maven" tutorial introducing some additional dependencies and I got stuck into a strange resolver behavior.

What I tried to do is to add datastax cassandra driver bundles to the recipe and implement a simple key-value store based on cassandra.

In bndtools + eclipse (no standalone mode) I managed to resolve and generate the following bndrun configuration:

-runbundles: \
 com.datastax.driver.core;version='[3.1.0,3.1.1)',\
 com.datastax.driver.extras;version='[3.1.0,3.1.1)',\
 com.datastax.driver.mapping;version='[3.1.0,3.1.1)',\
 com.google.guava;version='[19.0.0,19.0.1)',\
 io.dropwizard.metrics.core;version='[3.1.2,3.1.3)',\
 io.netty.buffer;version='[4.0.37,4.0.38)',\
 io.netty.codec;version='[4.0.37,4.0.38)',\
 io.netty.common;version='[4.0.37,4.0.38)',\
 io.netty.handler;version='[4.0.37,4.0.38)',\
 io.netty.transport;version='[4.0.37,4.0.38)',\
 joda-time;version='[2.8.2,2.8.3)',\
 org.apache.commons.lang3;version='[3.4.0,3.4.1)',\
 org.apache.felix.configadmin;version='[1.8.6,1.8.7)',\
 org.apache.felix.log;version='[1.0.1,1.0.2)',\
 org.apache.felix.scr;version='[2.0.0,2.0.1)',\
 org.eclipse.equinox.metatype;version='[1.4.100,1.4.101)',\
 org.osgi.service.metatype;version='[1.3.0,1.3.1)',\
 osgi.enroute.hamcrest.wrapper;version='[1.3.0,1.3.1)',\
 osgi.enroute.junit.wrapper;version='[4.12.0,4.12.1)',\
 osgi.enroute.logger.simple.provider;version='[1.1.1,1.1.2)'

and everything works quite fine. But in the standalone mode, when I run the mvn install command from the bndrun project folder I get the following error:

[INFO]
[INFO] --- bnd-export-maven-plugin:3.4.0-SNAPSHOT:export (default) @ example.cassandra.bndrun ---
?? prop: project.parent.version
?? prop: project.parent.version
?? prop: project.parent.version
?? prop: project.parent.version
?? prop: project.parent.version
?? prop: os.detected.classifier
?? prop: os.detected.classifier
?? prop: os.detected.classifier
?? prop: os.detected.classifier


-runbundles: \
 com.flairbit.example.cassandra.impl; version='[1.0.0,1.0.1)',\
 org.apache.felix.configadmin; version='[1.8.8,1.8.9)',\
 org.apache.felix.log; version='[1.0.1,1.0.2)',\
 org.apache.felix.scr; version='[2.0.2,2.0.3)',\
 org.eclipse.equinox.metatype; version='[1.4.100,1.4.101)',\
 org.osgi.service.metatype; version='[1.3.0,1.3.1)'


[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9.887 s
[INFO] Finished at: 2016-10-19T15:58:40+02:00
[INFO] Final Memory: 26M/496M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal biz.aQute.bnd:bnd-export-maven-plugin:3.4.0-SNAPSHOT:export (default) on project example.cassandra.bndrun: The runbundles have changed. Failing the build -> [Help 1]
[ERROR]
[ERROR] ...

What does "The runbundles have changed" error mean?

You can find the project I'm working on at the following link: https://github.com/mrulli/bnd.maven.only.test

Thanks,

matteo

[Christian Schneider]

On 19.10.2016 16:16, Matteo Rulli wrote:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9.887 s
[INFO] Finished at: 2016-10-19T15:58:40+02:00
[INFO] Final Memory: 26M/496M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal biz.aQute.bnd:bnd-export-maven-plugin:3.4.0-SNAPSHOT:export (default) on project example.cassandra.bndrun: The runbundles have changed. Failing the build -> [Help 1]
[ERROR]
[ERROR] ...

What does "The runbundles have changed" error mean?

The error means that the resolver found a solution that differs from the runbundles you already have.
This is a precaution that you do not accidently override a resolution.
You then have to overwrite the runbundles by hand.

For fully automated builds it makes sense to let maven create the runbundles automatically. You can add this config option to achieve this:

<failOnChanges>false</failOnChanges>

Christian

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[Matteo Rulli]

Thank you for your quick answer Christian!

Indeed setting the failOnChanges properties did the trick: I simply had to clean the bndrun/target, bndrun/generated and bndrun/bin folders and run again the mvn install command.

The strange thing is that I did not have any runbundles directive in my bndrun originally: so I do not fully understand why I need this failOnChanges config.

Besides, from time to time mvn install fails with a NPE inside the bnd-export-maven-plugin: as soon as I manage to reproduce the error I'll report the full stacktrace.

Thank you again,

matteo

[Matteo Rulli]

Here is the stacktrace for the NPE I was mentioning before:

[ERROR] Failed to execute goal biz.aQute.bnd:bnd-export-maven-plugin:3.4.0-SNAPSHOT:export (default) on project example.cassandra.bndrun: null: MojoExecutionException: NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal biz.aQute.bnd:bnd-export-maven-plugin:3.4.0-SNAPSHOT:export (default) on project example.cassandra.bndrun: null
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException
 at aQute.bnd.maven.export.plugin.ExportMojo.execute(ExportMojo.java:52)
 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
 ... 19 more
Caused by: java.lang.NullPointerException
 at org.apache.felix.resolver.Candidates.prepare(Candidates.java:946)
 at org.apache.felix.resolver.ResolverImpl.getInitialCandidates(ResolverImpl.java:502)
 at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:387)
 at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375)
 at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:329)
 at biz.aQute.resolve.BndResolver.resolve(BndResolver.java:29)
 at biz.aQute.resolve.ResolveProcess.resolveRequired(ResolveProcess.java:75)
 at biz.aQute.resolve.ProjectResolver.resolve(ProjectResolver.java:109)
 at biz.aQute.resolve.ProjectResolver.getRunBundles(ProjectResolver.java:126)
 at aQute.bnd.maven.export.plugin.ExportMojo.resolve(ExportMojo.java:86)
 at aQute.bnd.maven.export.plugin.ExportMojo.export(ExportMojo.java:70)
 at aQute.bnd.maven.export.plugin.ExportMojo.execute(ExportMojo.java:49)
 ... 21 more

If I run the mvn install command twice, the second attempt completes without errors.

Matteo

[Raymond Auge]

Would you mind tracking this stacktrace in a bnd issue including as much information as you can.

Sincerely,

- Ray

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

[Matteo Rulli]

Done: https://github.com/bndtools/bnd/issues/1754

Sorry, it's not a very detailed issue and I did not narrow down the problem yet: I'll try to investigate this a little bit more asap.

However, the project that generates the issue is on github and it should be reasonably simple to reproduce the problem.

matteo

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.