Hi
Good to hear that we may drop the <bundle> extension, nice work.
For camel-core I have thought of build the manifest.mf by hand so we
can better control it. It seems the bundle plugin has its issues with
different versions to build it, as you say.
Have you tried testing any of these JARs in OSGi? It would be good if
you try that and install some of the examples in a karaf 4 container
and see how it runs.
For lambda code in the existing source code then we cannot do that for
code that need to be backported to 2.17 and 2.16 branches. We can only
use lambdas in new code that is not to be backported.
For Camel 3.0 we can then covert the code to use lambads all over
where applicable. There is likely some tools in IDEA or Eclipse etc
that can assist with that.
And Camel end users can use lamdas today with their own code, also
with older Camel versions on java 8.
It may be that those people are using a new bundle plugin, or more
likely not using OSGi at all.
I would like to see more OSGi testing on this branch before any merge.
OSGi is complex and pain to maintain and build modules. So we need to
be sure we are on a path that we can do this. There is 250+ maven
modules that are build as OSGi so it better have to work for us.
But I really like that the bundle plugin is just generating a
MANIFEST.MF file that the JAR plugin just slurps in. Can it not be
configured somehow so the generated MANIFEST.MF is not replace so end
users do not need to do anything with a JAR plugin?
On Sat, Mar 26, 2016 at 1:09 AM, Raul Kripalani <ra...@apache.org> wrote:
> 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>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
