There is good news, bad news, and good news again ;-)
*Good news:* Now that Camel 2.18 is officially on JDK8, we can use lambdas
in our code. Woohoo!
*Bad news:* Our current Maven build breaks when doing so.
This is what happens:
1. maven-bundle-plugin version 2.3.x cannot parse JDK8 lambdas. [1]
2. Upgrading it to the latest version (3.0.1) makes the plugin fail
miserably (at least on camel-core).
3. Using the latest 2.x version of the maven-bundle-plugin (2.5.4) makes
the maven-shade-plugin fail with this error in turn:
[ERROR] The project main artifact does not exist. This could have the
following
[ERROR] reasons:
[ERROR] - You have invoked the goal directly from the command line. This is
not
[ERROR] supported. Please add the goal to the default lifecycle via an
[ERROR] <execution> element in your POM and use "mvn package" to have it
run.
[ERROR] - You have bound the goal to a lifecycle phase before "package".
Please
[ERROR] remove this binding from your POM such that the goal will be run
in
[ERROR] the proper phase.
4. Upgrading the shade plugin doesn't help.
5. The situation is dirty :P
The problem is the usage of the 'bundle' custom packaging type enabled by
extensions='true' in the maven-bundle-plugin.
*Good news again:*
We can avoid the problem by reverting back to the standard 'jar' packaging
type, which even puts us in a less brittle situation wrt. to future Maven
plugins we may want to add/upgrade. This implies:
1. Calling the maven-bundle-plugin:manifest goal (instead of the bundle
goal) to only generate the MANIFEST.MF.
2. Adding it to the JAR via an option in the the maven-jar-plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>${maven-jar-plugin-version}</version>
<configuration>
<archive>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
I've made the change. But since it's a big one, I didn't push to master but
to a branch for us to review first: jdk8-lambdas.
The build passes (yay!) but OSGi battle testing is a must to ensure there
are no regressions.
Could you have a quick look? If no feedback is received until Monday EOD,
I'll merge to master. If feedback is positive, we can merge earlier to
enable people to develop with lambdas finally.
---
Just in case you're not aware, the OSGi legend Neil Bartlett has just
released a new bnd-maven-plugin [2] that claims to overcome such
dysfunctions, as well as others, of the Felix plugin. He complained about
how the custom packaging type breaks integration with other plugins
downstream (what we're experiencing).
I see no reason to migrate to his bnd-maven-plugin, but we should keep it
in mind for the future.
[1] https://issues.apache.org/jira/browse/FELIX-4005
[2] http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html
Cheers,
*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
Blog: raul.io | twitter: @raulvk <https://twitter.com/raulvk>
