You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Raul Kripalani <ra...@apache.org> on 2016/03/26 01:09:51 UTC

Usage of Lambdas in our Maven build (jdk8-lambdas branch)

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>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I’d like to try the bnd-maven-plugin, but I can’t get the build to work on the branch.

When I run

mvn -DskipTests clean install

I get

[ERROR] Failed to execute goal org.codehaus.mojo:ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) on project maven-plugins: Artifact does not contain any legal files: maven-plugins-2.18-SNAPSHOT.jar -> [Help 1]

What am I doing wrong here?


> On Mar 27, 2016, at 10:24 AM, Claus Ibsen <cl...@gmail.com> wrote:
> 
> Hi
> 
> I got the OSGi tests to work with karaf 4 and they are all passing now
> for the features tests. There is a few that has been @Ignored because
> of known issues. eg we need a new SMX bundle for them.
> 
> You can run these tests reliable using a bash script
> 
> cd tests/camel-itest-karaf
> ./run-tests.sh
> 
> You can also try running using mvn with
> 
> mvn clean install
> 
> But the latter tend to break on my computer after 20 or so tests. The
> scripts runs reliable and it also cleanup dangling karaf JVMs. But
> generally its been safer to run one mvn goal per test it seems.
> 
> I also fixed the mistakes in karaf features and the tests so they are
> working again.
> 
> Raul you should be able to use that on your branch to give the osgi tests a go.
> 
> 
> 
> 
> 
> 
> On Sat, Mar 26, 2016 at 5:47 PM, Claus Ibsen <cl...@gmail.com> wrote:
>> I managed to get the CI jobs to complete now with setting higher memory.
>> 
>> The snapshots are now deployed and the CI jobs for osgi is triggered
>> 
>> Triggering a new build of Camel.trunk.itest.karaf
>> Triggering a new build of Camel.trunk.itest.osgi
>> Finished: SUCCESS
>> 
>> 
>> 
>> On Sat, Mar 26, 2016 at 12:36 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>> Oh I forgot the CI jobs are here
>>> https://builds.apache.org/view/A-D/view/Camel/
>>> 
>>> I got the link from Mueller. Beforehand it was hard/impossible to find
>>> Camel from
>>> https://builds.apache.org/
>>> 
>>> So I was for a longer time not able to see all these jobs, and just
>>> got the CI emails to look at.
>>> 
>>> But the OSGi jobs rely on the SNAPSHOT of Camel has been built prior
>>> to that, and that job is unreliable. I think we need to look at making
>>> the -notest also publish the SNAPSHOT to the snapshot mvn repo, so the
>>> CI jobs can pickup these new JARs.
>>> 
>>> If we get that more reliable then Camel end users can also easier use
>>> SNAPSHOT instead of having to build locally to be sure they get a
>>> clean build of it, otherwise you can end up with mixed builds or
>>> stale/old snapshots.
>>> 
>>> 
>>> 
>>> On Sat, Mar 26, 2016 at 12:33 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>>> On Sat, Mar 26, 2016 at 12:12 PM, Raul Kripalani <ra...@apache.org> wrote:
>>>>> Agree with your points.
>>>>> 
>>>>> 1. If you use lambdas on 2.18, you can't backport the code.
>>>>> 
>>>>> 2. I'll spend some time this weekend installing the bundles on Karaf. Karaf
>>>>> 4 is OK, or are we sticking with older versions for 2.x?
>>>>> 
>>>> 
>>>> Karaf 2.x is dropped. Use Karaf 4.x as the primary karaf version.
>>>> We may want to add a -Pkaraf3 profile to run against older Karaf 3.x containers.
>>>> 
>>>> 
>>>>> 3. I'll also run our OSGi itests, but it may be worth having Jenkins do all
>>>>> this. Could you configure a job in JKS to build this branch? I don't have
>>>>> job admin rights I believe.
>>>>> 
>>>> 
>>>> We already have some CI jobs to run 2 osgi based tests
>>>> 
>>>> - tests/camel-itest-karaf
>>>> - tests/camel-itest-osgi
>>>> 
>>>> The former tests that the Camel component can be installed, it does
>>>> this using pax-exam to bootup karaf and install the camel-xxx feature
>>>> and find the component and then tear down the test.
>>>> 
>>>> You can run these tests with the -Pkaraf4 profile.
>>>> But mind I had trouble with these tests may stop after 20 or so tests
>>>> and leave some karaf JVMs dangling. There is a kill-karaf.sh script to
>>>> kill em.
>>>> 
>>>> The camel-itest-osgi is likely in some state where some tests would
>>>> fail even for older branches. But these are unit tests that run Camel
>>>> apps in karaf and do some testing stuff like we do in regular
>>>> component tests. This has not yet been migrated to karaf 4, and run on
>>>> karaf 2.x. But you can give it a go and see how bad/good it is. It
>>>> used to be able to run almost all tests and pass. And we had also had
>>>> periods where everything was green.
>>>> 
>>>> However people dont write so many osgi tests so this module do not
>>>> have so much love. And there are plenty of components that are not
>>>> being tested.
>>>> 
>>>> 
>>>>> 4. It's necessary to configure the maven-jar-plugin to explicitly use a
>>>>> manifest file, otherwise the plugin generates its own. Originally I tried
>>>>> adding the config to the build plugins in the parent POM, but it failed for
>>>>> artifacts of type=maven-plugin. Hence I placed it in pluginManagement and
>>>>> then incorporated it in those intermediate POMs (components, examples,
>>>>> etc.) whose children built normal JARs. However, I ended up tracing the
>>>>> issue to a conflict introduced by the config of the maven-jar-plugin that
>>>>> maven-plugin injects, and solved it with a couple
>>>>> of combine.self="override". Hence, I think I might be able to push our
>>>>> maven-jar-plugin config back to the parent POM and to the build section.
>>>>> 
>>>> 
>>>> Ah okay. I am okay with we can do "anything" we need to build all the
>>>> Camel components and whatnot.
>>>> 
>>>> Its more what the impact is for end users. If we can make out examples
>>>> and maven archetypes simpler and easier that would be cool. But mind
>>>> that not all examples are osgi examples.
>>>> 
>>>> But it looks promising your work - thanks for starting this hard work.
>>>> 
>>>> 
>>>> 
>>>>> 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>
>>>>> 
>>>>> On Sat, Mar 26, 2016 at 10:12 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>> 
>>>>>> 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
>>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>> 
>>> 
>>> 
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>> 
>> 
>> 
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
> 
> 
> 
> -- 
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Raul Kripalani <ra...@apache.org>.
On Tue, Mar 29, 2016 at 2:27 PM, Quinn Stevenson <
quinn@pronoia-solutions.com> wrote:

> I was able to get the bnd-maven-plugin working with camel-core last night
> on the jdk8-lambda branch.  I still need to finish the bnd.bnd
> configuration file to make the manifests match, but I’m getting close.
> Once Raul finishes his work and merges it back to master, I’ll get the PR
> going with the bnd-maven-plugin so everyone can see what that looks like.
>
> Is there a list of which projects should not generate bundles?  I’d like
> to try and build that into my PR as well.
>

Cool, Quinn, nice work!

At the root of your working copy:

    find . -type f -name "pom.xml" -exec grep -H camel.osgi.skip {} \;

That should output the path to the poms that are skipping OSGi bundle
generation. Take into account that the property is inherited by children
poms.

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>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I was able to get the bnd-maven-plugin working with camel-core last night on the jdk8-lambda branch.  I still need to finish the bnd.bnd configuration file to make the manifests match, but I’m getting close.  Once Raul finishes his work and merges it back to master, I’ll get the PR going with the bnd-maven-plugin so everyone can see what that looks like.

Is there a list of which projects should not generate bundles?  I’d like to try and build that into my PR as well.


> On Mar 28, 2016, at 11:21 PM, Claus Ibsen <cl...@gmail.com> wrote:
> 
> On Tue, Mar 29, 2016 at 1:04 AM, Raul Kripalani <raulk@apache.org <ma...@apache.org>> wrote:
>> Thanks a lot Claus!
>> 
>> Given that we now make no distinction between bundles and standard JARs
>> through the packaging type, I was having the OSGi MANIFEST generation
>> triggered for bundles where its irrelevant, e.g. camel-grape,
>> camel-spring-boot, many examples, etc. So I added a profile which is
>> activated by default and is disabled through a new POM property
>> camel.osgi.skip, which I added to the POMs of such modules.
>> 
> 
> Can we flip the switch so you have to enable it on the maven modules
> that you want to be an osgi bundle. I am asking because people who are
> not using OSGi should really not see camel.osgi.skip=true in the
> examples / camel-spring-boot-starter etc.
> 
> They should be clean and without any osgi stuff.
> 
> Also I would rather make it explicit that this maven module is built
> as an osgi bundle if it has camel.osgi=true.
> 
> 
> 
> 
>> I was also able to upgrade the version of the maven-bundle-plugin to the
>> latest 3.0.1.
>> 
>> Hopefully I'll be able to finish my tests tomorrow and merge the branch
>> into master for a full test in JKS.
>> 
>> From then on... let the lambda fun begin (for features we don't intend to
>> backport)!
>> 
>> 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>
>> 
>> On Sun, Mar 27, 2016 at 5:24 PM, Claus Ibsen <cl...@gmail.com> wrote:
>> 
>>> Hi
>>> 
>>> I got the OSGi tests to work with karaf 4 and they are all passing now
>>> for the features tests. There is a few that has been @Ignored because
>>> of known issues. eg we need a new SMX bundle for them.
>>> 
>>> You can run these tests reliable using a bash script
>>> 
>>> cd tests/camel-itest-karaf
>>> ./run-tests.sh
>>> 
>>> You can also try running using mvn with
>>> 
>>> mvn clean install
>>> 
>>> But the latter tend to break on my computer after 20 or so tests. The
>>> scripts runs reliable and it also cleanup dangling karaf JVMs. But
>>> generally its been safer to run one mvn goal per test it seems.
>>> 
>>> I also fixed the mistakes in karaf features and the tests so they are
>>> working again.
>>> 
>>> Raul you should be able to use that on your branch to give the osgi tests
>>> a go.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Sat, Mar 26, 2016 at 5:47 PM, Claus Ibsen <cl...@gmail.com>
>>> wrote:
>>>> I managed to get the CI jobs to complete now with setting higher memory.
>>>> 
>>>> The snapshots are now deployed and the CI jobs for osgi is triggered
>>>> 
>>>> Triggering a new build of Camel.trunk.itest.karaf
>>>> Triggering a new build of Camel.trunk.itest.osgi
>>>> Finished: SUCCESS
>>>> 
>>>> 
>>>> 
>>>> On Sat, Mar 26, 2016 at 12:36 PM, Claus Ibsen <cl...@gmail.com>
>>> wrote:
>>>>> Oh I forgot the CI jobs are here
>>>>> https://builds.apache.org/view/A-D/view/Camel/
>>>>> 
>>>>> I got the link from Mueller. Beforehand it was hard/impossible to find
>>>>> Camel from
>>>>> https://builds.apache.org/
>>>>> 
>>>>> So I was for a longer time not able to see all these jobs, and just
>>>>> got the CI emails to look at.
>>>>> 
>>>>> But the OSGi jobs rely on the SNAPSHOT of Camel has been built prior
>>>>> to that, and that job is unreliable. I think we need to look at making
>>>>> the -notest also publish the SNAPSHOT to the snapshot mvn repo, so the
>>>>> CI jobs can pickup these new JARs.
>>>>> 
>>>>> If we get that more reliable then Camel end users can also easier use
>>>>> SNAPSHOT instead of having to build locally to be sure they get a
>>>>> clean build of it, otherwise you can end up with mixed builds or
>>>>> stale/old snapshots.
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sat, Mar 26, 2016 at 12:33 PM, Claus Ibsen <cl...@gmail.com>
>>> wrote:
>>>>>> On Sat, Mar 26, 2016 at 12:12 PM, Raul Kripalani <ra...@apache.org>
>>> wrote:
>>>>>>> Agree with your points.
>>>>>>> 
>>>>>>> 1. If you use lambdas on 2.18, you can't backport the code.
>>>>>>> 
>>>>>>> 2. I'll spend some time this weekend installing the bundles on Karaf.
>>> Karaf
>>>>>>> 4 is OK, or are we sticking with older versions for 2.x?
>>>>>>> 
>>>>>> 
>>>>>> Karaf 2.x is dropped. Use Karaf 4.x as the primary karaf version.
>>>>>> We may want to add a -Pkaraf3 profile to run against older Karaf 3.x
>>> containers.
>>>>>> 
>>>>>> 
>>>>>>> 3. I'll also run our OSGi itests, but it may be worth having Jenkins
>>> do all
>>>>>>> this. Could you configure a job in JKS to build this branch? I don't
>>> have
>>>>>>> job admin rights I believe.
>>>>>>> 
>>>>>> 
>>>>>> We already have some CI jobs to run 2 osgi based tests
>>>>>> 
>>>>>> - tests/camel-itest-karaf
>>>>>> - tests/camel-itest-osgi
>>>>>> 
>>>>>> The former tests that the Camel component can be installed, it does
>>>>>> this using pax-exam to bootup karaf and install the camel-xxx feature
>>>>>> and find the component and then tear down the test.
>>>>>> 
>>>>>> You can run these tests with the -Pkaraf4 profile.
>>>>>> But mind I had trouble with these tests may stop after 20 or so tests
>>>>>> and leave some karaf JVMs dangling. There is a kill-karaf.sh script to
>>>>>> kill em.
>>>>>> 
>>>>>> The camel-itest-osgi is likely in some state where some tests would
>>>>>> fail even for older branches. But these are unit tests that run Camel
>>>>>> apps in karaf and do some testing stuff like we do in regular
>>>>>> component tests. This has not yet been migrated to karaf 4, and run on
>>>>>> karaf 2.x. But you can give it a go and see how bad/good it is. It
>>>>>> used to be able to run almost all tests and pass. And we had also had
>>>>>> periods where everything was green.
>>>>>> 
>>>>>> However people dont write so many osgi tests so this module do not
>>>>>> have so much love. And there are plenty of components that are not
>>>>>> being tested.
>>>>>> 
>>>>>> 
>>>>>>> 4. It's necessary to configure the maven-jar-plugin to explicitly use
>>> a
>>>>>>> manifest file, otherwise the plugin generates its own. Originally I
>>> tried
>>>>>>> adding the config to the build plugins in the parent POM, but it
>>> failed for
>>>>>>> artifacts of type=maven-plugin. Hence I placed it in pluginManagement
>>> and
>>>>>>> then incorporated it in those intermediate POMs (components, examples,
>>>>>>> etc.) whose children built normal JARs. However, I ended up tracing
>>> the
>>>>>>> issue to a conflict introduced by the config of the maven-jar-plugin
>>> that
>>>>>>> maven-plugin injects, and solved it with a couple
>>>>>>> of combine.self="override". Hence, I think I might be able to push our
>>>>>>> maven-jar-plugin config back to the parent POM and to the build
>>> section.
>>>>>>> 
>>>>>> 
>>>>>> Ah okay. I am okay with we can do "anything" we need to build all the
>>>>>> Camel components and whatnot.
>>>>>> 
>>>>>> Its more what the impact is for end users. If we can make out examples
>>>>>> and maven archetypes simpler and easier that would be cool. But mind
>>>>>> that not all examples are osgi examples.
>>>>>> 
>>>>>> But it looks promising your work - thanks for starting this hard work.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 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>
>>>>>>> 
>>>>>>> On Sat, Mar 26, 2016 at 10:12 AM, Claus Ibsen <cl...@gmail.com>
>>> wrote:
>>>>>>> 
>>>>>>>> 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
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> -----------------
>>>>>> http://davsclaus.com @davsclaus
>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> http://davsclaus.com @davsclaus
>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>> 
>>> 
>>> 
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>> 
> 
> 
> 
> -- 
> Claus Ibsen
> -----------------
> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
There’s a JIRA to correct this too https://issues.apache.org/jira/browse/CAMEL-4232


> On Mar 30, 2016, at 12:00 PM, Claus Ibsen <cl...@gmail.com> wrote:
> 
> On Wed, Mar 30, 2016 at 5:12 PM, Raul Kripalani <raul@evosent.com <ma...@evosent.com>> wrote:
>> Yep, today, hopefully.
>> 
>> Faced a few complications with the Camel Blueprint and Camel Spring
>> bundles, which were inlining other modules via the bundle plugin.
>> 
> 
> Yeah there is some ant tasks that copy the source of camel-core-osgi
> and camel-core-xml AFAIR.
> There were OSGi problems back then to make those as individual bundles.
> So having it all in the same bundle made it work.
> 
> 
>> Cheers,
>> Raúl.
>> On 30 Mar 2016 16:06, "Quinn Stevenson" <qu...@pronoia-solutions.com> wrote:
>> 
>>> Any updates on when this will be merged?  I have a couple of PRs I’m
>>> working on that this effects.
>>> 
>>> 
>>>> On Mar 29, 2016, at 11:12 AM, Quinn Stevenson <
>>> quinn@pronoia-solutions.com> wrote:
>>>> 
>>>> For the JARs that will not be bundles - what do we want in the
>>> MANIFEST.MF?
>>>> 
>>>> 
>>>>> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <claus.ibsen@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>>> 
>>>>> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org
>>> <ma...@apache.org>> wrote:
>>>>>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ibsen@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>>>> 
>>>>>>> Can we flip the switch so you have to enable it on the maven modules
>>>>>>> that you want to be an osgi bundle. I am asking because people who are
>>>>>>> not using OSGi should really not see camel.osgi.skip=true in the
>>>>>>> examples / camel-spring-boot-starter etc.
>>>>>>> 
>>>>>>> They should be clean and without any osgi stuff.
>>>>>>> 
>>>>>>> Also I would rather make it explicit that this maven module is built
>>>>>>> as an osgi bundle if it has camel.osgi=true.
>>>>>>> 
>>>>>> 
>>>>>> I see your point. What I'll do is make the activation rely on property
>>>>>> value comparison rather than property presence, e.g.
>>> camel.osgi=true/false.
>>>>>> That way, we can set camel.osgi=true on components/pom.xml, and exclude
>>>>>> only the few components that are not OSGi by setting camel.osgi=false
>>> on
>>>>>> their POMs.
>>>>>> For the examples, we can set camel.osgi=false on examples/pom.xml, and
>>> only
>>>>>> set the property to true on those examples that are meant to be
>>> bundles.
>>>>>> Let's play with value rather than presence/absence, because once you
>>> set a
>>>>>> property up the chain in the Maven reactor, I don't think you can
>>> unset it
>>>>>> (or can you?).
>>>>>> 
>>>>>> Although... Approaching it from a different angle, it may be worth to
>>>>>> explicitly define the build plugins in each example POM. Thus we can
>>>>>> attempt to make the example "self-contained".
>>>>>> 
>>>>> 
>>>>> Yeah would love to make the examples self container without a parent.
>>>>> And then they should import the Camel BOM instead (aka camel parent).
>>>>> 
>>>>> Then end users can just copy those and adjust them as needed.
>>>>> 
>>>>> Not sure if we have tried this in the past and had trouble with the
>>>>> release build?
>>>>> And there is 50+ examples so a fair bit of work to migrate. But we
>>>>> have a big community so people can help with this.
>>>>> 
>>>>> 
>>>>>> That would take more work, so I won't do it now, but just wanted to
>>> hear
>>>>>> your thoughts.
>>>>>> 
>>>>> 
>>>>> Yeah sounds good.
>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> *Raúl Kripalani*
>>>>>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
>>> and
>>>>>> Messaging Engineer
>>>>>> http://about.me/raulkripalani <http://about.me/raulkripalani> |
>>> http://www.linkedin.com/in/raulkripalani <
>>> http://www.linkedin.com/in/raulkripalani>
>>>>>> Blog: raul.io <http://raul.io/> | twitter: @raulvk <
>>> https://twitter.com/raulvk <https://twitter.com/raulvk>>
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>>>>> Camel in Action 2: https://www.manning.com/ibsen2 <
>>> https://www.manning.com/ibsen2>
>>> 
>>> 
> 
> 
> 
> -- 
> Claus Ibsen
> -----------------
> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
Hi

Okay I fixed some missing files in camel-core that somehow the old way included.

Some of those missing files causes unit tests to fail in spring, that
test loading some model metadata from camel-core JAR.

That all now works.

So we are left with 3 components not working in OSGi due some double
package exports

- camel-ftp
- camel-mvel
- camel-ognl

We are almost there.



On Thu, Mar 31, 2016 at 10:05 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> I see this little WARN when its building camel-parent
>
> [INFO] --- maven-bundle-plugin:3.0.1:manifest (bundle-manifest) @
> camel-parent ---
> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
>
> We should filter out packaging=pom if possible so the bundle plugin do
> not run on these.
>
>
>
> On Thu, Mar 31, 2016 at 8:52 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> Hi
>>
>> So far I got
>>
>> ftp
>> mvel
>>
>> components to fail in the osgi tests. Have not checked why.
>>
>> On Wed, Mar 30, 2016 at 9:24 PM, Raul Kripalani <ra...@apache.org> wrote:
>>> Changes are pushed now. First commit with lambdas done too ;-)
>>>
>>> Gotta keep an eye on Jenkins tonight.
>>>
>>> BTW - OSGi Karaf tests were 100% OK. Thanks for the script, Claus.
>>>
>>> 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>
>>>
>>> On Wed, Mar 30, 2016 at 7:00 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>>
>>>> On Wed, Mar 30, 2016 at 5:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
>>>> > Yep, today, hopefully.
>>>> >
>>>> > Faced a few complications with the Camel Blueprint and Camel Spring
>>>> > bundles, which were inlining other modules via the bundle plugin.
>>>> >
>>>>
>>>> Yeah there is some ant tasks that copy the source of camel-core-osgi
>>>> and camel-core-xml AFAIR.
>>>> There were OSGi problems back then to make those as individual bundles.
>>>> So having it all in the same bundle made it work.
>>>>
>>>>
>>>> > Cheers,
>>>> > Raúl.
>>>> > On 30 Mar 2016 16:06, "Quinn Stevenson" <qu...@pronoia-solutions.com>
>>>> wrote:
>>>> >
>>>> >> Any updates on when this will be merged?  I have a couple of PRs I’m
>>>> >> working on that this effects.
>>>> >>
>>>> >>
>>>> >> > On Mar 29, 2016, at 11:12 AM, Quinn Stevenson <
>>>> >> quinn@pronoia-solutions.com> wrote:
>>>> >> >
>>>> >> > For the JARs that will not be bundles - what do we want in the
>>>> >> MANIFEST.MF?
>>>> >> >
>>>> >> >
>>>> >> >> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <claus.ibsen@gmail.com
>>>> >> <ma...@gmail.com>> wrote:
>>>> >> >>
>>>> >> >> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org
>>>> >> <ma...@apache.org>> wrote:
>>>> >> >>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ibsen@gmail.com
>>>> >> <ma...@gmail.com>> wrote:
>>>> >> >>>
>>>> >> >>>> Can we flip the switch so you have to enable it on the maven
>>>> modules
>>>> >> >>>> that you want to be an osgi bundle. I am asking because people who
>>>> are
>>>> >> >>>> not using OSGi should really not see camel.osgi.skip=true in the
>>>> >> >>>> examples / camel-spring-boot-starter etc.
>>>> >> >>>>
>>>> >> >>>> They should be clean and without any osgi stuff.
>>>> >> >>>>
>>>> >> >>>> Also I would rather make it explicit that this maven module is
>>>> built
>>>> >> >>>> as an osgi bundle if it has camel.osgi=true.
>>>> >> >>>>
>>>> >> >>>
>>>> >> >>> I see your point. What I'll do is make the activation rely on
>>>> property
>>>> >> >>> value comparison rather than property presence, e.g.
>>>> >> camel.osgi=true/false.
>>>> >> >>> That way, we can set camel.osgi=true on components/pom.xml, and
>>>> exclude
>>>> >> >>> only the few components that are not OSGi by setting
>>>> camel.osgi=false
>>>> >> on
>>>> >> >>> their POMs.
>>>> >> >>> For the examples, we can set camel.osgi=false on examples/pom.xml,
>>>> and
>>>> >> only
>>>> >> >>> set the property to true on those examples that are meant to be
>>>> >> bundles.
>>>> >> >>> Let's play with value rather than presence/absence, because once you
>>>> >> set a
>>>> >> >>> property up the chain in the Maven reactor, I don't think you can
>>>> >> unset it
>>>> >> >>> (or can you?).
>>>> >> >>>
>>>> >> >>> Although... Approaching it from a different angle, it may be worth
>>>> to
>>>> >> >>> explicitly define the build plugins in each example POM. Thus we can
>>>> >> >>> attempt to make the example "self-contained".
>>>> >> >>>
>>>> >> >>
>>>> >> >> Yeah would love to make the examples self container without a parent.
>>>> >> >> And then they should import the Camel BOM instead (aka camel parent).
>>>> >> >>
>>>> >> >> Then end users can just copy those and adjust them as needed.
>>>> >> >>
>>>> >> >> Not sure if we have tried this in the past and had trouble with the
>>>> >> >> release build?
>>>> >> >> And there is 50+ examples so a fair bit of work to migrate. But we
>>>> >> >> have a big community so people can help with this.
>>>> >> >>
>>>> >> >>
>>>> >> >>> That would take more work, so I won't do it now, but just wanted to
>>>> >> hear
>>>> >> >>> your thoughts.
>>>> >> >>>
>>>> >> >>
>>>> >> >> Yeah sounds good.
>>>> >> >>
>>>> >> >>> Cheers,
>>>> >> >>>
>>>> >> >>> *Raúl Kripalani*
>>>> >> >>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
>>>> Data
>>>> >> and
>>>> >> >>> Messaging Engineer
>>>> >> >>> http://about.me/raulkripalani <http://about.me/raulkripalani> |
>>>> >> http://www.linkedin.com/in/raulkripalani <
>>>> >> http://www.linkedin.com/in/raulkripalani>
>>>> >> >>> Blog: raul.io <http://raul.io/> | twitter: @raulvk <
>>>> >> https://twitter.com/raulvk <https://twitter.com/raulvk>>
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> --
>>>> >> >> Claus Ibsen
>>>> >> >> -----------------
>>>> >> >> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>>>> >> >> Camel in Action 2: https://www.manning.com/ibsen2 <
>>>> >> https://www.manning.com/ibsen2>
>>>> >>
>>>> >>
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
Hi

I see this little WARN when its building camel-parent

[INFO] --- maven-bundle-plugin:3.0.1:manifest (bundle-manifest) @
camel-parent ---
[WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]

We should filter out packaging=pom if possible so the bundle plugin do
not run on these.



On Thu, Mar 31, 2016 at 8:52 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> So far I got
>
> ftp
> mvel
>
> components to fail in the osgi tests. Have not checked why.
>
> On Wed, Mar 30, 2016 at 9:24 PM, Raul Kripalani <ra...@apache.org> wrote:
>> Changes are pushed now. First commit with lambdas done too ;-)
>>
>> Gotta keep an eye on Jenkins tonight.
>>
>> BTW - OSGi Karaf tests were 100% OK. Thanks for the script, Claus.
>>
>> 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>
>>
>> On Wed, Mar 30, 2016 at 7:00 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>
>>> On Wed, Mar 30, 2016 at 5:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
>>> > Yep, today, hopefully.
>>> >
>>> > Faced a few complications with the Camel Blueprint and Camel Spring
>>> > bundles, which were inlining other modules via the bundle plugin.
>>> >
>>>
>>> Yeah there is some ant tasks that copy the source of camel-core-osgi
>>> and camel-core-xml AFAIR.
>>> There were OSGi problems back then to make those as individual bundles.
>>> So having it all in the same bundle made it work.
>>>
>>>
>>> > Cheers,
>>> > Raúl.
>>> > On 30 Mar 2016 16:06, "Quinn Stevenson" <qu...@pronoia-solutions.com>
>>> wrote:
>>> >
>>> >> Any updates on when this will be merged?  I have a couple of PRs I’m
>>> >> working on that this effects.
>>> >>
>>> >>
>>> >> > On Mar 29, 2016, at 11:12 AM, Quinn Stevenson <
>>> >> quinn@pronoia-solutions.com> wrote:
>>> >> >
>>> >> > For the JARs that will not be bundles - what do we want in the
>>> >> MANIFEST.MF?
>>> >> >
>>> >> >
>>> >> >> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <claus.ibsen@gmail.com
>>> >> <ma...@gmail.com>> wrote:
>>> >> >>
>>> >> >> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org
>>> >> <ma...@apache.org>> wrote:
>>> >> >>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ibsen@gmail.com
>>> >> <ma...@gmail.com>> wrote:
>>> >> >>>
>>> >> >>>> Can we flip the switch so you have to enable it on the maven
>>> modules
>>> >> >>>> that you want to be an osgi bundle. I am asking because people who
>>> are
>>> >> >>>> not using OSGi should really not see camel.osgi.skip=true in the
>>> >> >>>> examples / camel-spring-boot-starter etc.
>>> >> >>>>
>>> >> >>>> They should be clean and without any osgi stuff.
>>> >> >>>>
>>> >> >>>> Also I would rather make it explicit that this maven module is
>>> built
>>> >> >>>> as an osgi bundle if it has camel.osgi=true.
>>> >> >>>>
>>> >> >>>
>>> >> >>> I see your point. What I'll do is make the activation rely on
>>> property
>>> >> >>> value comparison rather than property presence, e.g.
>>> >> camel.osgi=true/false.
>>> >> >>> That way, we can set camel.osgi=true on components/pom.xml, and
>>> exclude
>>> >> >>> only the few components that are not OSGi by setting
>>> camel.osgi=false
>>> >> on
>>> >> >>> their POMs.
>>> >> >>> For the examples, we can set camel.osgi=false on examples/pom.xml,
>>> and
>>> >> only
>>> >> >>> set the property to true on those examples that are meant to be
>>> >> bundles.
>>> >> >>> Let's play with value rather than presence/absence, because once you
>>> >> set a
>>> >> >>> property up the chain in the Maven reactor, I don't think you can
>>> >> unset it
>>> >> >>> (or can you?).
>>> >> >>>
>>> >> >>> Although... Approaching it from a different angle, it may be worth
>>> to
>>> >> >>> explicitly define the build plugins in each example POM. Thus we can
>>> >> >>> attempt to make the example "self-contained".
>>> >> >>>
>>> >> >>
>>> >> >> Yeah would love to make the examples self container without a parent.
>>> >> >> And then they should import the Camel BOM instead (aka camel parent).
>>> >> >>
>>> >> >> Then end users can just copy those and adjust them as needed.
>>> >> >>
>>> >> >> Not sure if we have tried this in the past and had trouble with the
>>> >> >> release build?
>>> >> >> And there is 50+ examples so a fair bit of work to migrate. But we
>>> >> >> have a big community so people can help with this.
>>> >> >>
>>> >> >>
>>> >> >>> That would take more work, so I won't do it now, but just wanted to
>>> >> hear
>>> >> >>> your thoughts.
>>> >> >>>
>>> >> >>
>>> >> >> Yeah sounds good.
>>> >> >>
>>> >> >>> Cheers,
>>> >> >>>
>>> >> >>> *Raúl Kripalani*
>>> >> >>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
>>> Data
>>> >> and
>>> >> >>> Messaging Engineer
>>> >> >>> http://about.me/raulkripalani <http://about.me/raulkripalani> |
>>> >> http://www.linkedin.com/in/raulkripalani <
>>> >> http://www.linkedin.com/in/raulkripalani>
>>> >> >>> Blog: raul.io <http://raul.io/> | twitter: @raulvk <
>>> >> https://twitter.com/raulvk <https://twitter.com/raulvk>>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Claus Ibsen
>>> >> >> -----------------
>>> >> >> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>>> >> >> Camel in Action 2: https://www.manning.com/ibsen2 <
>>> >> https://www.manning.com/ibsen2>
>>> >>
>>> >>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
Hi

So far I got

ftp
mvel

components to fail in the osgi tests. Have not checked why.

On Wed, Mar 30, 2016 at 9:24 PM, Raul Kripalani <ra...@apache.org> wrote:
> Changes are pushed now. First commit with lambdas done too ;-)
>
> Gotta keep an eye on Jenkins tonight.
>
> BTW - OSGi Karaf tests were 100% OK. Thanks for the script, Claus.
>
> 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>
>
> On Wed, Mar 30, 2016 at 7:00 PM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Wed, Mar 30, 2016 at 5:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
>> > Yep, today, hopefully.
>> >
>> > Faced a few complications with the Camel Blueprint and Camel Spring
>> > bundles, which were inlining other modules via the bundle plugin.
>> >
>>
>> Yeah there is some ant tasks that copy the source of camel-core-osgi
>> and camel-core-xml AFAIR.
>> There were OSGi problems back then to make those as individual bundles.
>> So having it all in the same bundle made it work.
>>
>>
>> > Cheers,
>> > Raúl.
>> > On 30 Mar 2016 16:06, "Quinn Stevenson" <qu...@pronoia-solutions.com>
>> wrote:
>> >
>> >> Any updates on when this will be merged?  I have a couple of PRs I’m
>> >> working on that this effects.
>> >>
>> >>
>> >> > On Mar 29, 2016, at 11:12 AM, Quinn Stevenson <
>> >> quinn@pronoia-solutions.com> wrote:
>> >> >
>> >> > For the JARs that will not be bundles - what do we want in the
>> >> MANIFEST.MF?
>> >> >
>> >> >
>> >> >> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <claus.ibsen@gmail.com
>> >> <ma...@gmail.com>> wrote:
>> >> >>
>> >> >> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org
>> >> <ma...@apache.org>> wrote:
>> >> >>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ibsen@gmail.com
>> >> <ma...@gmail.com>> wrote:
>> >> >>>
>> >> >>>> Can we flip the switch so you have to enable it on the maven
>> modules
>> >> >>>> that you want to be an osgi bundle. I am asking because people who
>> are
>> >> >>>> not using OSGi should really not see camel.osgi.skip=true in the
>> >> >>>> examples / camel-spring-boot-starter etc.
>> >> >>>>
>> >> >>>> They should be clean and without any osgi stuff.
>> >> >>>>
>> >> >>>> Also I would rather make it explicit that this maven module is
>> built
>> >> >>>> as an osgi bundle if it has camel.osgi=true.
>> >> >>>>
>> >> >>>
>> >> >>> I see your point. What I'll do is make the activation rely on
>> property
>> >> >>> value comparison rather than property presence, e.g.
>> >> camel.osgi=true/false.
>> >> >>> That way, we can set camel.osgi=true on components/pom.xml, and
>> exclude
>> >> >>> only the few components that are not OSGi by setting
>> camel.osgi=false
>> >> on
>> >> >>> their POMs.
>> >> >>> For the examples, we can set camel.osgi=false on examples/pom.xml,
>> and
>> >> only
>> >> >>> set the property to true on those examples that are meant to be
>> >> bundles.
>> >> >>> Let's play with value rather than presence/absence, because once you
>> >> set a
>> >> >>> property up the chain in the Maven reactor, I don't think you can
>> >> unset it
>> >> >>> (or can you?).
>> >> >>>
>> >> >>> Although... Approaching it from a different angle, it may be worth
>> to
>> >> >>> explicitly define the build plugins in each example POM. Thus we can
>> >> >>> attempt to make the example "self-contained".
>> >> >>>
>> >> >>
>> >> >> Yeah would love to make the examples self container without a parent.
>> >> >> And then they should import the Camel BOM instead (aka camel parent).
>> >> >>
>> >> >> Then end users can just copy those and adjust them as needed.
>> >> >>
>> >> >> Not sure if we have tried this in the past and had trouble with the
>> >> >> release build?
>> >> >> And there is 50+ examples so a fair bit of work to migrate. But we
>> >> >> have a big community so people can help with this.
>> >> >>
>> >> >>
>> >> >>> That would take more work, so I won't do it now, but just wanted to
>> >> hear
>> >> >>> your thoughts.
>> >> >>>
>> >> >>
>> >> >> Yeah sounds good.
>> >> >>
>> >> >>> Cheers,
>> >> >>>
>> >> >>> *Raúl Kripalani*
>> >> >>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
>> Data
>> >> and
>> >> >>> Messaging Engineer
>> >> >>> http://about.me/raulkripalani <http://about.me/raulkripalani> |
>> >> http://www.linkedin.com/in/raulkripalani <
>> >> http://www.linkedin.com/in/raulkripalani>
>> >> >>> Blog: raul.io <http://raul.io/> | twitter: @raulvk <
>> >> https://twitter.com/raulvk <https://twitter.com/raulvk>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Claus Ibsen
>> >> >> -----------------
>> >> >> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>> >> >> Camel in Action 2: https://www.manning.com/ibsen2 <
>> >> https://www.manning.com/ibsen2>
>> >>
>> >>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
Hi

Sounds good.

Btw the camel archetypes in tooling/archetypes need to be changed as
well. There is some that builds OSGi projects. It would be better if
we build those like we do build Camel itself now.



On Wed, Mar 30, 2016 at 9:24 PM, Raul Kripalani <ra...@apache.org> wrote:
> Changes are pushed now. First commit with lambdas done too ;-)
>
> Gotta keep an eye on Jenkins tonight.
>
> BTW - OSGi Karaf tests were 100% OK. Thanks for the script, Claus.
>
> 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>
>
> On Wed, Mar 30, 2016 at 7:00 PM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Wed, Mar 30, 2016 at 5:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
>> > Yep, today, hopefully.
>> >
>> > Faced a few complications with the Camel Blueprint and Camel Spring
>> > bundles, which were inlining other modules via the bundle plugin.
>> >
>>
>> Yeah there is some ant tasks that copy the source of camel-core-osgi
>> and camel-core-xml AFAIR.
>> There were OSGi problems back then to make those as individual bundles.
>> So having it all in the same bundle made it work.
>>
>>
>> > Cheers,
>> > Raúl.
>> > On 30 Mar 2016 16:06, "Quinn Stevenson" <qu...@pronoia-solutions.com>
>> wrote:
>> >
>> >> Any updates on when this will be merged?  I have a couple of PRs I’m
>> >> working on that this effects.
>> >>
>> >>
>> >> > On Mar 29, 2016, at 11:12 AM, Quinn Stevenson <
>> >> quinn@pronoia-solutions.com> wrote:
>> >> >
>> >> > For the JARs that will not be bundles - what do we want in the
>> >> MANIFEST.MF?
>> >> >
>> >> >
>> >> >> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <claus.ibsen@gmail.com
>> >> <ma...@gmail.com>> wrote:
>> >> >>
>> >> >> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org
>> >> <ma...@apache.org>> wrote:
>> >> >>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ibsen@gmail.com
>> >> <ma...@gmail.com>> wrote:
>> >> >>>
>> >> >>>> Can we flip the switch so you have to enable it on the maven
>> modules
>> >> >>>> that you want to be an osgi bundle. I am asking because people who
>> are
>> >> >>>> not using OSGi should really not see camel.osgi.skip=true in the
>> >> >>>> examples / camel-spring-boot-starter etc.
>> >> >>>>
>> >> >>>> They should be clean and without any osgi stuff.
>> >> >>>>
>> >> >>>> Also I would rather make it explicit that this maven module is
>> built
>> >> >>>> as an osgi bundle if it has camel.osgi=true.
>> >> >>>>
>> >> >>>
>> >> >>> I see your point. What I'll do is make the activation rely on
>> property
>> >> >>> value comparison rather than property presence, e.g.
>> >> camel.osgi=true/false.
>> >> >>> That way, we can set camel.osgi=true on components/pom.xml, and
>> exclude
>> >> >>> only the few components that are not OSGi by setting
>> camel.osgi=false
>> >> on
>> >> >>> their POMs.
>> >> >>> For the examples, we can set camel.osgi=false on examples/pom.xml,
>> and
>> >> only
>> >> >>> set the property to true on those examples that are meant to be
>> >> bundles.
>> >> >>> Let's play with value rather than presence/absence, because once you
>> >> set a
>> >> >>> property up the chain in the Maven reactor, I don't think you can
>> >> unset it
>> >> >>> (or can you?).
>> >> >>>
>> >> >>> Although... Approaching it from a different angle, it may be worth
>> to
>> >> >>> explicitly define the build plugins in each example POM. Thus we can
>> >> >>> attempt to make the example "self-contained".
>> >> >>>
>> >> >>
>> >> >> Yeah would love to make the examples self container without a parent.
>> >> >> And then they should import the Camel BOM instead (aka camel parent).
>> >> >>
>> >> >> Then end users can just copy those and adjust them as needed.
>> >> >>
>> >> >> Not sure if we have tried this in the past and had trouble with the
>> >> >> release build?
>> >> >> And there is 50+ examples so a fair bit of work to migrate. But we
>> >> >> have a big community so people can help with this.
>> >> >>
>> >> >>
>> >> >>> That would take more work, so I won't do it now, but just wanted to
>> >> hear
>> >> >>> your thoughts.
>> >> >>>
>> >> >>
>> >> >> Yeah sounds good.
>> >> >>
>> >> >>> Cheers,
>> >> >>>
>> >> >>> *Raúl Kripalani*
>> >> >>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
>> Data
>> >> and
>> >> >>> Messaging Engineer
>> >> >>> http://about.me/raulkripalani <http://about.me/raulkripalani> |
>> >> http://www.linkedin.com/in/raulkripalani <
>> >> http://www.linkedin.com/in/raulkripalani>
>> >> >>> Blog: raul.io <http://raul.io/> | twitter: @raulvk <
>> >> https://twitter.com/raulvk <https://twitter.com/raulvk>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Claus Ibsen
>> >> >> -----------------
>> >> >> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>> >> >> Camel in Action 2: https://www.manning.com/ibsen2 <
>> >> https://www.manning.com/ibsen2>
>> >>
>> >>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Thanks Raul -

I’ll finish up the PR for https://issues.apache.org/jira/browse/CAMEL-6132 ASAP.  The changes in this one also help with the OSGi tests - I think I’ve got it so they don’t leave Karaf instances hanging around anymore.  


> On Mar 30, 2016, at 1:24 PM, Raul Kripalani <ra...@apache.org> wrote:
> 
> Changes are pushed now. First commit with lambdas done too ;-)
> 
> Gotta keep an eye on Jenkins tonight.
> 
> BTW - OSGi Karaf tests were 100% OK. Thanks for the script, Claus.
> 
> 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>
> 
> On Wed, Mar 30, 2016 at 7:00 PM, Claus Ibsen <cl...@gmail.com> wrote:
> 
>> On Wed, Mar 30, 2016 at 5:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
>>> Yep, today, hopefully.
>>> 
>>> Faced a few complications with the Camel Blueprint and Camel Spring
>>> bundles, which were inlining other modules via the bundle plugin.
>>> 
>> 
>> Yeah there is some ant tasks that copy the source of camel-core-osgi
>> and camel-core-xml AFAIR.
>> There were OSGi problems back then to make those as individual bundles.
>> So having it all in the same bundle made it work.
>> 
>> 
>>> Cheers,
>>> Raúl.
>>> On 30 Mar 2016 16:06, "Quinn Stevenson" <qu...@pronoia-solutions.com>
>> wrote:
>>> 
>>>> Any updates on when this will be merged?  I have a couple of PRs I’m
>>>> working on that this effects.
>>>> 
>>>> 
>>>>> On Mar 29, 2016, at 11:12 AM, Quinn Stevenson <
>>>> quinn@pronoia-solutions.com> wrote:
>>>>> 
>>>>> For the JARs that will not be bundles - what do we want in the
>>>> MANIFEST.MF?
>>>>> 
>>>>> 
>>>>>> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <claus.ibsen@gmail.com
>>>> <ma...@gmail.com>> wrote:
>>>>>> 
>>>>>> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org
>>>> <ma...@apache.org>> wrote:
>>>>>>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ibsen@gmail.com
>>>> <ma...@gmail.com>> wrote:
>>>>>>> 
>>>>>>>> Can we flip the switch so you have to enable it on the maven
>> modules
>>>>>>>> that you want to be an osgi bundle. I am asking because people who
>> are
>>>>>>>> not using OSGi should really not see camel.osgi.skip=true in the
>>>>>>>> examples / camel-spring-boot-starter etc.
>>>>>>>> 
>>>>>>>> They should be clean and without any osgi stuff.
>>>>>>>> 
>>>>>>>> Also I would rather make it explicit that this maven module is
>> built
>>>>>>>> as an osgi bundle if it has camel.osgi=true.
>>>>>>>> 
>>>>>>> 
>>>>>>> I see your point. What I'll do is make the activation rely on
>> property
>>>>>>> value comparison rather than property presence, e.g.
>>>> camel.osgi=true/false.
>>>>>>> That way, we can set camel.osgi=true on components/pom.xml, and
>> exclude
>>>>>>> only the few components that are not OSGi by setting
>> camel.osgi=false
>>>> on
>>>>>>> their POMs.
>>>>>>> For the examples, we can set camel.osgi=false on examples/pom.xml,
>> and
>>>> only
>>>>>>> set the property to true on those examples that are meant to be
>>>> bundles.
>>>>>>> Let's play with value rather than presence/absence, because once you
>>>> set a
>>>>>>> property up the chain in the Maven reactor, I don't think you can
>>>> unset it
>>>>>>> (or can you?).
>>>>>>> 
>>>>>>> Although... Approaching it from a different angle, it may be worth
>> to
>>>>>>> explicitly define the build plugins in each example POM. Thus we can
>>>>>>> attempt to make the example "self-contained".
>>>>>>> 
>>>>>> 
>>>>>> Yeah would love to make the examples self container without a parent.
>>>>>> And then they should import the Camel BOM instead (aka camel parent).
>>>>>> 
>>>>>> Then end users can just copy those and adjust them as needed.
>>>>>> 
>>>>>> Not sure if we have tried this in the past and had trouble with the
>>>>>> release build?
>>>>>> And there is 50+ examples so a fair bit of work to migrate. But we
>>>>>> have a big community so people can help with this.
>>>>>> 
>>>>>> 
>>>>>>> That would take more work, so I won't do it now, but just wanted to
>>>> hear
>>>>>>> your thoughts.
>>>>>>> 
>>>>>> 
>>>>>> Yeah sounds good.
>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> *Raúl Kripalani*
>>>>>>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
>> Data
>>>> and
>>>>>>> Messaging Engineer
>>>>>>> http://about.me/raulkripalani <http://about.me/raulkripalani> |
>>>> http://www.linkedin.com/in/raulkripalani <
>>>> http://www.linkedin.com/in/raulkripalani>
>>>>>>> Blog: raul.io <http://raul.io/> | twitter: @raulvk <
>>>> https://twitter.com/raulvk <https://twitter.com/raulvk>>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> -----------------
>>>>>> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>>>>>> Camel in Action 2: https://www.manning.com/ibsen2 <
>>>> https://www.manning.com/ibsen2>
>>>> 
>>>> 
>> 
>> 
>> 
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Raul Kripalani <ra...@apache.org>.
Changes are pushed now. First commit with lambdas done too ;-)

Gotta keep an eye on Jenkins tonight.

BTW - OSGi Karaf tests were 100% OK. Thanks for the script, Claus.

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>

On Wed, Mar 30, 2016 at 7:00 PM, Claus Ibsen <cl...@gmail.com> wrote:

> On Wed, Mar 30, 2016 at 5:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
> > Yep, today, hopefully.
> >
> > Faced a few complications with the Camel Blueprint and Camel Spring
> > bundles, which were inlining other modules via the bundle plugin.
> >
>
> Yeah there is some ant tasks that copy the source of camel-core-osgi
> and camel-core-xml AFAIR.
> There were OSGi problems back then to make those as individual bundles.
> So having it all in the same bundle made it work.
>
>
> > Cheers,
> > Raúl.
> > On 30 Mar 2016 16:06, "Quinn Stevenson" <qu...@pronoia-solutions.com>
> wrote:
> >
> >> Any updates on when this will be merged?  I have a couple of PRs I’m
> >> working on that this effects.
> >>
> >>
> >> > On Mar 29, 2016, at 11:12 AM, Quinn Stevenson <
> >> quinn@pronoia-solutions.com> wrote:
> >> >
> >> > For the JARs that will not be bundles - what do we want in the
> >> MANIFEST.MF?
> >> >
> >> >
> >> >> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <claus.ibsen@gmail.com
> >> <ma...@gmail.com>> wrote:
> >> >>
> >> >> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org
> >> <ma...@apache.org>> wrote:
> >> >>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ibsen@gmail.com
> >> <ma...@gmail.com>> wrote:
> >> >>>
> >> >>>> Can we flip the switch so you have to enable it on the maven
> modules
> >> >>>> that you want to be an osgi bundle. I am asking because people who
> are
> >> >>>> not using OSGi should really not see camel.osgi.skip=true in the
> >> >>>> examples / camel-spring-boot-starter etc.
> >> >>>>
> >> >>>> They should be clean and without any osgi stuff.
> >> >>>>
> >> >>>> Also I would rather make it explicit that this maven module is
> built
> >> >>>> as an osgi bundle if it has camel.osgi=true.
> >> >>>>
> >> >>>
> >> >>> I see your point. What I'll do is make the activation rely on
> property
> >> >>> value comparison rather than property presence, e.g.
> >> camel.osgi=true/false.
> >> >>> That way, we can set camel.osgi=true on components/pom.xml, and
> exclude
> >> >>> only the few components that are not OSGi by setting
> camel.osgi=false
> >> on
> >> >>> their POMs.
> >> >>> For the examples, we can set camel.osgi=false on examples/pom.xml,
> and
> >> only
> >> >>> set the property to true on those examples that are meant to be
> >> bundles.
> >> >>> Let's play with value rather than presence/absence, because once you
> >> set a
> >> >>> property up the chain in the Maven reactor, I don't think you can
> >> unset it
> >> >>> (or can you?).
> >> >>>
> >> >>> Although... Approaching it from a different angle, it may be worth
> to
> >> >>> explicitly define the build plugins in each example POM. Thus we can
> >> >>> attempt to make the example "self-contained".
> >> >>>
> >> >>
> >> >> Yeah would love to make the examples self container without a parent.
> >> >> And then they should import the Camel BOM instead (aka camel parent).
> >> >>
> >> >> Then end users can just copy those and adjust them as needed.
> >> >>
> >> >> Not sure if we have tried this in the past and had trouble with the
> >> >> release build?
> >> >> And there is 50+ examples so a fair bit of work to migrate. But we
> >> >> have a big community so people can help with this.
> >> >>
> >> >>
> >> >>> That would take more work, so I won't do it now, but just wanted to
> >> hear
> >> >>> your thoughts.
> >> >>>
> >> >>
> >> >> Yeah sounds good.
> >> >>
> >> >>> Cheers,
> >> >>>
> >> >>> *Raúl Kripalani*
> >> >>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
> Data
> >> and
> >> >>> Messaging Engineer
> >> >>> http://about.me/raulkripalani <http://about.me/raulkripalani> |
> >> http://www.linkedin.com/in/raulkripalani <
> >> http://www.linkedin.com/in/raulkripalani>
> >> >>> Blog: raul.io <http://raul.io/> | twitter: @raulvk <
> >> https://twitter.com/raulvk <https://twitter.com/raulvk>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Claus Ibsen
> >> >> -----------------
> >> >> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> >> >> Camel in Action 2: https://www.manning.com/ibsen2 <
> >> https://www.manning.com/ibsen2>
> >>
> >>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Mar 30, 2016 at 5:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
> Yep, today, hopefully.
>
> Faced a few complications with the Camel Blueprint and Camel Spring
> bundles, which were inlining other modules via the bundle plugin.
>

Yeah there is some ant tasks that copy the source of camel-core-osgi
and camel-core-xml AFAIR.
There were OSGi problems back then to make those as individual bundles.
So having it all in the same bundle made it work.


> Cheers,
> Raúl.
> On 30 Mar 2016 16:06, "Quinn Stevenson" <qu...@pronoia-solutions.com> wrote:
>
>> Any updates on when this will be merged?  I have a couple of PRs I’m
>> working on that this effects.
>>
>>
>> > On Mar 29, 2016, at 11:12 AM, Quinn Stevenson <
>> quinn@pronoia-solutions.com> wrote:
>> >
>> > For the JARs that will not be bundles - what do we want in the
>> MANIFEST.MF?
>> >
>> >
>> >> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <claus.ibsen@gmail.com
>> <ma...@gmail.com>> wrote:
>> >>
>> >> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org
>> <ma...@apache.org>> wrote:
>> >>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ibsen@gmail.com
>> <ma...@gmail.com>> wrote:
>> >>>
>> >>>> Can we flip the switch so you have to enable it on the maven modules
>> >>>> that you want to be an osgi bundle. I am asking because people who are
>> >>>> not using OSGi should really not see camel.osgi.skip=true in the
>> >>>> examples / camel-spring-boot-starter etc.
>> >>>>
>> >>>> They should be clean and without any osgi stuff.
>> >>>>
>> >>>> Also I would rather make it explicit that this maven module is built
>> >>>> as an osgi bundle if it has camel.osgi=true.
>> >>>>
>> >>>
>> >>> I see your point. What I'll do is make the activation rely on property
>> >>> value comparison rather than property presence, e.g.
>> camel.osgi=true/false.
>> >>> That way, we can set camel.osgi=true on components/pom.xml, and exclude
>> >>> only the few components that are not OSGi by setting camel.osgi=false
>> on
>> >>> their POMs.
>> >>> For the examples, we can set camel.osgi=false on examples/pom.xml, and
>> only
>> >>> set the property to true on those examples that are meant to be
>> bundles.
>> >>> Let's play with value rather than presence/absence, because once you
>> set a
>> >>> property up the chain in the Maven reactor, I don't think you can
>> unset it
>> >>> (or can you?).
>> >>>
>> >>> Although... Approaching it from a different angle, it may be worth to
>> >>> explicitly define the build plugins in each example POM. Thus we can
>> >>> attempt to make the example "self-contained".
>> >>>
>> >>
>> >> Yeah would love to make the examples self container without a parent.
>> >> And then they should import the Camel BOM instead (aka camel parent).
>> >>
>> >> Then end users can just copy those and adjust them as needed.
>> >>
>> >> Not sure if we have tried this in the past and had trouble with the
>> >> release build?
>> >> And there is 50+ examples so a fair bit of work to migrate. But we
>> >> have a big community so people can help with this.
>> >>
>> >>
>> >>> That would take more work, so I won't do it now, but just wanted to
>> hear
>> >>> your thoughts.
>> >>>
>> >>
>> >> Yeah sounds good.
>> >>
>> >>> Cheers,
>> >>>
>> >>> *Raúl Kripalani*
>> >>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
>> and
>> >>> Messaging Engineer
>> >>> http://about.me/raulkripalani <http://about.me/raulkripalani> |
>> http://www.linkedin.com/in/raulkripalani <
>> http://www.linkedin.com/in/raulkripalani>
>> >>> Blog: raul.io <http://raul.io/> | twitter: @raulvk <
>> https://twitter.com/raulvk <https://twitter.com/raulvk>>
>> >>
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> -----------------
>> >> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>> >> Camel in Action 2: https://www.manning.com/ibsen2 <
>> https://www.manning.com/ibsen2>
>>
>>



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Raul Kripalani <ra...@evosent.com>.
Yep, today, hopefully.

Faced a few complications with the Camel Blueprint and Camel Spring
bundles, which were inlining other modules via the bundle plugin.

Cheers,
Raúl.
On 30 Mar 2016 16:06, "Quinn Stevenson" <qu...@pronoia-solutions.com> wrote:

> Any updates on when this will be merged?  I have a couple of PRs I’m
> working on that this effects.
>
>
> > On Mar 29, 2016, at 11:12 AM, Quinn Stevenson <
> quinn@pronoia-solutions.com> wrote:
> >
> > For the JARs that will not be bundles - what do we want in the
> MANIFEST.MF?
> >
> >
> >> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <claus.ibsen@gmail.com
> <ma...@gmail.com>> wrote:
> >>
> >> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org
> <ma...@apache.org>> wrote:
> >>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ibsen@gmail.com
> <ma...@gmail.com>> wrote:
> >>>
> >>>> Can we flip the switch so you have to enable it on the maven modules
> >>>> that you want to be an osgi bundle. I am asking because people who are
> >>>> not using OSGi should really not see camel.osgi.skip=true in the
> >>>> examples / camel-spring-boot-starter etc.
> >>>>
> >>>> They should be clean and without any osgi stuff.
> >>>>
> >>>> Also I would rather make it explicit that this maven module is built
> >>>> as an osgi bundle if it has camel.osgi=true.
> >>>>
> >>>
> >>> I see your point. What I'll do is make the activation rely on property
> >>> value comparison rather than property presence, e.g.
> camel.osgi=true/false.
> >>> That way, we can set camel.osgi=true on components/pom.xml, and exclude
> >>> only the few components that are not OSGi by setting camel.osgi=false
> on
> >>> their POMs.
> >>> For the examples, we can set camel.osgi=false on examples/pom.xml, and
> only
> >>> set the property to true on those examples that are meant to be
> bundles.
> >>> Let's play with value rather than presence/absence, because once you
> set a
> >>> property up the chain in the Maven reactor, I don't think you can
> unset it
> >>> (or can you?).
> >>>
> >>> Although... Approaching it from a different angle, it may be worth to
> >>> explicitly define the build plugins in each example POM. Thus we can
> >>> attempt to make the example "self-contained".
> >>>
> >>
> >> Yeah would love to make the examples self container without a parent.
> >> And then they should import the Camel BOM instead (aka camel parent).
> >>
> >> Then end users can just copy those and adjust them as needed.
> >>
> >> Not sure if we have tried this in the past and had trouble with the
> >> release build?
> >> And there is 50+ examples so a fair bit of work to migrate. But we
> >> have a big community so people can help with this.
> >>
> >>
> >>> That would take more work, so I won't do it now, but just wanted to
> hear
> >>> your thoughts.
> >>>
> >>
> >> Yeah sounds good.
> >>
> >>> Cheers,
> >>>
> >>> *Raúl Kripalani*
> >>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
> and
> >>> Messaging Engineer
> >>> http://about.me/raulkripalani <http://about.me/raulkripalani> |
> http://www.linkedin.com/in/raulkripalani <
> http://www.linkedin.com/in/raulkripalani>
> >>> Blog: raul.io <http://raul.io/> | twitter: @raulvk <
> https://twitter.com/raulvk <https://twitter.com/raulvk>>
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2 <
> https://www.manning.com/ibsen2>
>
>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Any updates on when this will be merged?  I have a couple of PRs I’m working on that this effects.


> On Mar 29, 2016, at 11:12 AM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
> 
> For the JARs that will not be bundles - what do we want in the MANIFEST.MF?
> 
> 
>> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <claus.ibsen@gmail.com <ma...@gmail.com>> wrote:
>> 
>> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org <ma...@apache.org>> wrote:
>>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ibsen@gmail.com <ma...@gmail.com>> wrote:
>>> 
>>>> Can we flip the switch so you have to enable it on the maven modules
>>>> that you want to be an osgi bundle. I am asking because people who are
>>>> not using OSGi should really not see camel.osgi.skip=true in the
>>>> examples / camel-spring-boot-starter etc.
>>>> 
>>>> They should be clean and without any osgi stuff.
>>>> 
>>>> Also I would rather make it explicit that this maven module is built
>>>> as an osgi bundle if it has camel.osgi=true.
>>>> 
>>> 
>>> I see your point. What I'll do is make the activation rely on property
>>> value comparison rather than property presence, e.g. camel.osgi=true/false.
>>> That way, we can set camel.osgi=true on components/pom.xml, and exclude
>>> only the few components that are not OSGi by setting camel.osgi=false on
>>> their POMs.
>>> For the examples, we can set camel.osgi=false on examples/pom.xml, and only
>>> set the property to true on those examples that are meant to be bundles.
>>> Let's play with value rather than presence/absence, because once you set a
>>> property up the chain in the Maven reactor, I don't think you can unset it
>>> (or can you?).
>>> 
>>> Although... Approaching it from a different angle, it may be worth to
>>> explicitly define the build plugins in each example POM. Thus we can
>>> attempt to make the example "self-contained".
>>> 
>> 
>> Yeah would love to make the examples self container without a parent.
>> And then they should import the Camel BOM instead (aka camel parent).
>> 
>> Then end users can just copy those and adjust them as needed.
>> 
>> Not sure if we have tried this in the past and had trouble with the
>> release build?
>> And there is 50+ examples so a fair bit of work to migrate. But we
>> have a big community so people can help with this.
>> 
>> 
>>> That would take more work, so I won't do it now, but just wanted to hear
>>> your thoughts.
>>> 
>> 
>> Yeah sounds good.
>> 
>>> Cheers,
>>> 
>>> *Raúl Kripalani*
>>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
>>> Messaging Engineer
>>> http://about.me/raulkripalani <http://about.me/raulkripalani> | http://www.linkedin.com/in/raulkripalani <http://www.linkedin.com/in/raulkripalani>
>>> Blog: raul.io <http://raul.io/> | twitter: @raulvk <https://twitter.com/raulvk <https://twitter.com/raulvk>>
>> 
>> 
>> 
>> -- 
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
For the JARs that will not be bundles - what do we want in the MANIFEST.MF?


> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <cl...@gmail.com> wrote:
> 
> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org <ma...@apache.org>> wrote:
>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> 
>>> Can we flip the switch so you have to enable it on the maven modules
>>> that you want to be an osgi bundle. I am asking because people who are
>>> not using OSGi should really not see camel.osgi.skip=true in the
>>> examples / camel-spring-boot-starter etc.
>>> 
>>> They should be clean and without any osgi stuff.
>>> 
>>> Also I would rather make it explicit that this maven module is built
>>> as an osgi bundle if it has camel.osgi=true.
>>> 
>> 
>> I see your point. What I'll do is make the activation rely on property
>> value comparison rather than property presence, e.g. camel.osgi=true/false.
>> That way, we can set camel.osgi=true on components/pom.xml, and exclude
>> only the few components that are not OSGi by setting camel.osgi=false on
>> their POMs.
>> For the examples, we can set camel.osgi=false on examples/pom.xml, and only
>> set the property to true on those examples that are meant to be bundles.
>> Let's play with value rather than presence/absence, because once you set a
>> property up the chain in the Maven reactor, I don't think you can unset it
>> (or can you?).
>> 
>> Although... Approaching it from a different angle, it may be worth to
>> explicitly define the build plugins in each example POM. Thus we can
>> attempt to make the example "self-contained".
>> 
> 
> Yeah would love to make the examples self container without a parent.
> And then they should import the Camel BOM instead (aka camel parent).
> 
> Then end users can just copy those and adjust them as needed.
> 
> Not sure if we have tried this in the past and had trouble with the
> release build?
> And there is 50+ examples so a fair bit of work to migrate. But we
> have a big community so people can help with this.
> 
> 
>> That would take more work, so I won't do it now, but just wanted to hear
>> your thoughts.
>> 
> 
> Yeah sounds good.
> 
>> Cheers,
>> 
>> *Raúl Kripalani*
>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
>> Messaging Engineer
>> http://about.me/raulkripalani <http://about.me/raulkripalani> | http://www.linkedin.com/in/raulkripalani <http://www.linkedin.com/in/raulkripalani>
>> Blog: raul.io <http://raul.io/> | twitter: @raulvk <https://twitter.com/raulvk <https://twitter.com/raulvk>>
> 
> 
> 
> -- 
> Claus Ibsen
> -----------------
> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <ra...@apache.org> wrote:
> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> Can we flip the switch so you have to enable it on the maven modules
>> that you want to be an osgi bundle. I am asking because people who are
>> not using OSGi should really not see camel.osgi.skip=true in the
>> examples / camel-spring-boot-starter etc.
>>
>> They should be clean and without any osgi stuff.
>>
>> Also I would rather make it explicit that this maven module is built
>> as an osgi bundle if it has camel.osgi=true.
>>
>
> I see your point. What I'll do is make the activation rely on property
> value comparison rather than property presence, e.g. camel.osgi=true/false.
> That way, we can set camel.osgi=true on components/pom.xml, and exclude
> only the few components that are not OSGi by setting camel.osgi=false on
> their POMs.
> For the examples, we can set camel.osgi=false on examples/pom.xml, and only
> set the property to true on those examples that are meant to be bundles.
> Let's play with value rather than presence/absence, because once you set a
> property up the chain in the Maven reactor, I don't think you can unset it
> (or can you?).
>
> Although... Approaching it from a different angle, it may be worth to
> explicitly define the build plugins in each example POM. Thus we can
> attempt to make the example "self-contained".
>

Yeah would love to make the examples self container without a parent.
And then they should import the Camel BOM instead (aka camel parent).

Then end users can just copy those and adjust them as needed.

Not sure if we have tried this in the past and had trouble with the
release build?
And there is 50+ examples so a fair bit of work to migrate. But we
have a big community so people can help with this.


> That would take more work, so I won't do it now, but just wanted to hear
> your thoughts.
>

Yeah sounds good.

> 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

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Raul Kripalani <ra...@apache.org>.
On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <cl...@gmail.com> wrote:

> Can we flip the switch so you have to enable it on the maven modules
> that you want to be an osgi bundle. I am asking because people who are
> not using OSGi should really not see camel.osgi.skip=true in the
> examples / camel-spring-boot-starter etc.
>
> They should be clean and without any osgi stuff.
>
> Also I would rather make it explicit that this maven module is built
> as an osgi bundle if it has camel.osgi=true.
>

I see your point. What I'll do is make the activation rely on property
value comparison rather than property presence, e.g. camel.osgi=true/false.
That way, we can set camel.osgi=true on components/pom.xml, and exclude
only the few components that are not OSGi by setting camel.osgi=false on
their POMs.
For the examples, we can set camel.osgi=false on examples/pom.xml, and only
set the property to true on those examples that are meant to be bundles.
Let's play with value rather than presence/absence, because once you set a
property up the chain in the Maven reactor, I don't think you can unset it
(or can you?).

Although... Approaching it from a different angle, it may be worth to
explicitly define the build plugins in each example POM. Thus we can
attempt to make the example "self-contained".

That would take more work, so I won't do it now, but just wanted to hear
your thoughts.

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>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Mar 29, 2016 at 1:04 AM, Raul Kripalani <ra...@apache.org> wrote:
> Thanks a lot Claus!
>
> Given that we now make no distinction between bundles and standard JARs
> through the packaging type, I was having the OSGi MANIFEST generation
> triggered for bundles where its irrelevant, e.g. camel-grape,
> camel-spring-boot, many examples, etc. So I added a profile which is
> activated by default and is disabled through a new POM property
> camel.osgi.skip, which I added to the POMs of such modules.
>

Can we flip the switch so you have to enable it on the maven modules
that you want to be an osgi bundle. I am asking because people who are
not using OSGi should really not see camel.osgi.skip=true in the
examples / camel-spring-boot-starter etc.

They should be clean and without any osgi stuff.

Also I would rather make it explicit that this maven module is built
as an osgi bundle if it has camel.osgi=true.




> I was also able to upgrade the version of the maven-bundle-plugin to the
> latest 3.0.1.
>
> Hopefully I'll be able to finish my tests tomorrow and merge the branch
> into master for a full test in JKS.
>
> From then on... let the lambda fun begin (for features we don't intend to
> backport)!
>
> 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>
>
> On Sun, Mar 27, 2016 at 5:24 PM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> Hi
>>
>> I got the OSGi tests to work with karaf 4 and they are all passing now
>> for the features tests. There is a few that has been @Ignored because
>> of known issues. eg we need a new SMX bundle for them.
>>
>> You can run these tests reliable using a bash script
>>
>> cd tests/camel-itest-karaf
>> ./run-tests.sh
>>
>> You can also try running using mvn with
>>
>> mvn clean install
>>
>> But the latter tend to break on my computer after 20 or so tests. The
>> scripts runs reliable and it also cleanup dangling karaf JVMs. But
>> generally its been safer to run one mvn goal per test it seems.
>>
>> I also fixed the mistakes in karaf features and the tests so they are
>> working again.
>>
>> Raul you should be able to use that on your branch to give the osgi tests
>> a go.
>>
>>
>>
>>
>>
>>
>> On Sat, Mar 26, 2016 at 5:47 PM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>> > I managed to get the CI jobs to complete now with setting higher memory.
>> >
>> > The snapshots are now deployed and the CI jobs for osgi is triggered
>> >
>> > Triggering a new build of Camel.trunk.itest.karaf
>> > Triggering a new build of Camel.trunk.itest.osgi
>> > Finished: SUCCESS
>> >
>> >
>> >
>> > On Sat, Mar 26, 2016 at 12:36 PM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>> >> Oh I forgot the CI jobs are here
>> >> https://builds.apache.org/view/A-D/view/Camel/
>> >>
>> >> I got the link from Mueller. Beforehand it was hard/impossible to find
>> >> Camel from
>> >> https://builds.apache.org/
>> >>
>> >> So I was for a longer time not able to see all these jobs, and just
>> >> got the CI emails to look at.
>> >>
>> >> But the OSGi jobs rely on the SNAPSHOT of Camel has been built prior
>> >> to that, and that job is unreliable. I think we need to look at making
>> >> the -notest also publish the SNAPSHOT to the snapshot mvn repo, so the
>> >> CI jobs can pickup these new JARs.
>> >>
>> >> If we get that more reliable then Camel end users can also easier use
>> >> SNAPSHOT instead of having to build locally to be sure they get a
>> >> clean build of it, otherwise you can end up with mixed builds or
>> >> stale/old snapshots.
>> >>
>> >>
>> >>
>> >> On Sat, Mar 26, 2016 at 12:33 PM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>> >>> On Sat, Mar 26, 2016 at 12:12 PM, Raul Kripalani <ra...@apache.org>
>> wrote:
>> >>>> Agree with your points.
>> >>>>
>> >>>> 1. If you use lambdas on 2.18, you can't backport the code.
>> >>>>
>> >>>> 2. I'll spend some time this weekend installing the bundles on Karaf.
>> Karaf
>> >>>> 4 is OK, or are we sticking with older versions for 2.x?
>> >>>>
>> >>>
>> >>> Karaf 2.x is dropped. Use Karaf 4.x as the primary karaf version.
>> >>> We may want to add a -Pkaraf3 profile to run against older Karaf 3.x
>> containers.
>> >>>
>> >>>
>> >>>> 3. I'll also run our OSGi itests, but it may be worth having Jenkins
>> do all
>> >>>> this. Could you configure a job in JKS to build this branch? I don't
>> have
>> >>>> job admin rights I believe.
>> >>>>
>> >>>
>> >>> We already have some CI jobs to run 2 osgi based tests
>> >>>
>> >>> - tests/camel-itest-karaf
>> >>> - tests/camel-itest-osgi
>> >>>
>> >>> The former tests that the Camel component can be installed, it does
>> >>> this using pax-exam to bootup karaf and install the camel-xxx feature
>> >>> and find the component and then tear down the test.
>> >>>
>> >>> You can run these tests with the -Pkaraf4 profile.
>> >>> But mind I had trouble with these tests may stop after 20 or so tests
>> >>> and leave some karaf JVMs dangling. There is a kill-karaf.sh script to
>> >>> kill em.
>> >>>
>> >>> The camel-itest-osgi is likely in some state where some tests would
>> >>> fail even for older branches. But these are unit tests that run Camel
>> >>> apps in karaf and do some testing stuff like we do in regular
>> >>> component tests. This has not yet been migrated to karaf 4, and run on
>> >>> karaf 2.x. But you can give it a go and see how bad/good it is. It
>> >>> used to be able to run almost all tests and pass. And we had also had
>> >>> periods where everything was green.
>> >>>
>> >>> However people dont write so many osgi tests so this module do not
>> >>> have so much love. And there are plenty of components that are not
>> >>> being tested.
>> >>>
>> >>>
>> >>>> 4. It's necessary to configure the maven-jar-plugin to explicitly use
>> a
>> >>>> manifest file, otherwise the plugin generates its own. Originally I
>> tried
>> >>>> adding the config to the build plugins in the parent POM, but it
>> failed for
>> >>>> artifacts of type=maven-plugin. Hence I placed it in pluginManagement
>> and
>> >>>> then incorporated it in those intermediate POMs (components, examples,
>> >>>> etc.) whose children built normal JARs. However, I ended up tracing
>> the
>> >>>> issue to a conflict introduced by the config of the maven-jar-plugin
>> that
>> >>>> maven-plugin injects, and solved it with a couple
>> >>>> of combine.self="override". Hence, I think I might be able to push our
>> >>>> maven-jar-plugin config back to the parent POM and to the build
>> section.
>> >>>>
>> >>>
>> >>> Ah okay. I am okay with we can do "anything" we need to build all the
>> >>> Camel components and whatnot.
>> >>>
>> >>> Its more what the impact is for end users. If we can make out examples
>> >>> and maven archetypes simpler and easier that would be cool. But mind
>> >>> that not all examples are osgi examples.
>> >>>
>> >>> But it looks promising your work - thanks for starting this hard work.
>> >>>
>> >>>
>> >>>
>> >>>> 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>
>> >>>>
>> >>>> On Sat, Mar 26, 2016 at 10:12 AM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>> >>>>
>> >>>>> 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
>> >>>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Claus Ibsen
>> >>> -----------------
>> >>> http://davsclaus.com @davsclaus
>> >>> Camel in Action 2: https://www.manning.com/ibsen2
>> >>
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> -----------------
>> >> http://davsclaus.com @davsclaus
>> >> Camel in Action 2: https://www.manning.com/ibsen2
>> >
>> >
>> >
>> > --
>> > Claus Ibsen
>> > -----------------
>> > http://davsclaus.com @davsclaus
>> > Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Raul Kripalani <ra...@apache.org>.
Thanks a lot Claus!

Given that we now make no distinction between bundles and standard JARs
through the packaging type, I was having the OSGi MANIFEST generation
triggered for bundles where its irrelevant, e.g. camel-grape,
camel-spring-boot, many examples, etc. So I added a profile which is
activated by default and is disabled through a new POM property
camel.osgi.skip, which I added to the POMs of such modules.

I was also able to upgrade the version of the maven-bundle-plugin to the
latest 3.0.1.

Hopefully I'll be able to finish my tests tomorrow and merge the branch
into master for a full test in JKS.

>From then on... let the lambda fun begin (for features we don't intend to
backport)!

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>

On Sun, Mar 27, 2016 at 5:24 PM, Claus Ibsen <cl...@gmail.com> wrote:

> Hi
>
> I got the OSGi tests to work with karaf 4 and they are all passing now
> for the features tests. There is a few that has been @Ignored because
> of known issues. eg we need a new SMX bundle for them.
>
> You can run these tests reliable using a bash script
>
> cd tests/camel-itest-karaf
> ./run-tests.sh
>
> You can also try running using mvn with
>
> mvn clean install
>
> But the latter tend to break on my computer after 20 or so tests. The
> scripts runs reliable and it also cleanup dangling karaf JVMs. But
> generally its been safer to run one mvn goal per test it seems.
>
> I also fixed the mistakes in karaf features and the tests so they are
> working again.
>
> Raul you should be able to use that on your branch to give the osgi tests
> a go.
>
>
>
>
>
>
> On Sat, Mar 26, 2016 at 5:47 PM, Claus Ibsen <cl...@gmail.com>
> wrote:
> > I managed to get the CI jobs to complete now with setting higher memory.
> >
> > The snapshots are now deployed and the CI jobs for osgi is triggered
> >
> > Triggering a new build of Camel.trunk.itest.karaf
> > Triggering a new build of Camel.trunk.itest.osgi
> > Finished: SUCCESS
> >
> >
> >
> > On Sat, Mar 26, 2016 at 12:36 PM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >> Oh I forgot the CI jobs are here
> >> https://builds.apache.org/view/A-D/view/Camel/
> >>
> >> I got the link from Mueller. Beforehand it was hard/impossible to find
> >> Camel from
> >> https://builds.apache.org/
> >>
> >> So I was for a longer time not able to see all these jobs, and just
> >> got the CI emails to look at.
> >>
> >> But the OSGi jobs rely on the SNAPSHOT of Camel has been built prior
> >> to that, and that job is unreliable. I think we need to look at making
> >> the -notest also publish the SNAPSHOT to the snapshot mvn repo, so the
> >> CI jobs can pickup these new JARs.
> >>
> >> If we get that more reliable then Camel end users can also easier use
> >> SNAPSHOT instead of having to build locally to be sure they get a
> >> clean build of it, otherwise you can end up with mixed builds or
> >> stale/old snapshots.
> >>
> >>
> >>
> >> On Sat, Mar 26, 2016 at 12:33 PM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >>> On Sat, Mar 26, 2016 at 12:12 PM, Raul Kripalani <ra...@apache.org>
> wrote:
> >>>> Agree with your points.
> >>>>
> >>>> 1. If you use lambdas on 2.18, you can't backport the code.
> >>>>
> >>>> 2. I'll spend some time this weekend installing the bundles on Karaf.
> Karaf
> >>>> 4 is OK, or are we sticking with older versions for 2.x?
> >>>>
> >>>
> >>> Karaf 2.x is dropped. Use Karaf 4.x as the primary karaf version.
> >>> We may want to add a -Pkaraf3 profile to run against older Karaf 3.x
> containers.
> >>>
> >>>
> >>>> 3. I'll also run our OSGi itests, but it may be worth having Jenkins
> do all
> >>>> this. Could you configure a job in JKS to build this branch? I don't
> have
> >>>> job admin rights I believe.
> >>>>
> >>>
> >>> We already have some CI jobs to run 2 osgi based tests
> >>>
> >>> - tests/camel-itest-karaf
> >>> - tests/camel-itest-osgi
> >>>
> >>> The former tests that the Camel component can be installed, it does
> >>> this using pax-exam to bootup karaf and install the camel-xxx feature
> >>> and find the component and then tear down the test.
> >>>
> >>> You can run these tests with the -Pkaraf4 profile.
> >>> But mind I had trouble with these tests may stop after 20 or so tests
> >>> and leave some karaf JVMs dangling. There is a kill-karaf.sh script to
> >>> kill em.
> >>>
> >>> The camel-itest-osgi is likely in some state where some tests would
> >>> fail even for older branches. But these are unit tests that run Camel
> >>> apps in karaf and do some testing stuff like we do in regular
> >>> component tests. This has not yet been migrated to karaf 4, and run on
> >>> karaf 2.x. But you can give it a go and see how bad/good it is. It
> >>> used to be able to run almost all tests and pass. And we had also had
> >>> periods where everything was green.
> >>>
> >>> However people dont write so many osgi tests so this module do not
> >>> have so much love. And there are plenty of components that are not
> >>> being tested.
> >>>
> >>>
> >>>> 4. It's necessary to configure the maven-jar-plugin to explicitly use
> a
> >>>> manifest file, otherwise the plugin generates its own. Originally I
> tried
> >>>> adding the config to the build plugins in the parent POM, but it
> failed for
> >>>> artifacts of type=maven-plugin. Hence I placed it in pluginManagement
> and
> >>>> then incorporated it in those intermediate POMs (components, examples,
> >>>> etc.) whose children built normal JARs. However, I ended up tracing
> the
> >>>> issue to a conflict introduced by the config of the maven-jar-plugin
> that
> >>>> maven-plugin injects, and solved it with a couple
> >>>> of combine.self="override". Hence, I think I might be able to push our
> >>>> maven-jar-plugin config back to the parent POM and to the build
> section.
> >>>>
> >>>
> >>> Ah okay. I am okay with we can do "anything" we need to build all the
> >>> Camel components and whatnot.
> >>>
> >>> Its more what the impact is for end users. If we can make out examples
> >>> and maven archetypes simpler and easier that would be cool. But mind
> >>> that not all examples are osgi examples.
> >>>
> >>> But it looks promising your work - thanks for starting this hard work.
> >>>
> >>>
> >>>
> >>>> 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>
> >>>>
> >>>> On Sat, Mar 26, 2016 at 10:12 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >>>>
> >>>>> 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
> >>>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Claus Ibsen
> >>> -----------------
> >>> http://davsclaus.com @davsclaus
> >>> Camel in Action 2: https://www.manning.com/ibsen2
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> http://davsclaus.com @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
Hi

I got the OSGi tests to work with karaf 4 and they are all passing now
for the features tests. There is a few that has been @Ignored because
of known issues. eg we need a new SMX bundle for them.

You can run these tests reliable using a bash script

cd tests/camel-itest-karaf
./run-tests.sh

You can also try running using mvn with

mvn clean install

But the latter tend to break on my computer after 20 or so tests. The
scripts runs reliable and it also cleanup dangling karaf JVMs. But
generally its been safer to run one mvn goal per test it seems.

I also fixed the mistakes in karaf features and the tests so they are
working again.

Raul you should be able to use that on your branch to give the osgi tests a go.






On Sat, Mar 26, 2016 at 5:47 PM, Claus Ibsen <cl...@gmail.com> wrote:
> I managed to get the CI jobs to complete now with setting higher memory.
>
> The snapshots are now deployed and the CI jobs for osgi is triggered
>
> Triggering a new build of Camel.trunk.itest.karaf
> Triggering a new build of Camel.trunk.itest.osgi
> Finished: SUCCESS
>
>
>
> On Sat, Mar 26, 2016 at 12:36 PM, Claus Ibsen <cl...@gmail.com> wrote:
>> Oh I forgot the CI jobs are here
>> https://builds.apache.org/view/A-D/view/Camel/
>>
>> I got the link from Mueller. Beforehand it was hard/impossible to find
>> Camel from
>> https://builds.apache.org/
>>
>> So I was for a longer time not able to see all these jobs, and just
>> got the CI emails to look at.
>>
>> But the OSGi jobs rely on the SNAPSHOT of Camel has been built prior
>> to that, and that job is unreliable. I think we need to look at making
>> the -notest also publish the SNAPSHOT to the snapshot mvn repo, so the
>> CI jobs can pickup these new JARs.
>>
>> If we get that more reliable then Camel end users can also easier use
>> SNAPSHOT instead of having to build locally to be sure they get a
>> clean build of it, otherwise you can end up with mixed builds or
>> stale/old snapshots.
>>
>>
>>
>> On Sat, Mar 26, 2016 at 12:33 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>> On Sat, Mar 26, 2016 at 12:12 PM, Raul Kripalani <ra...@apache.org> wrote:
>>>> Agree with your points.
>>>>
>>>> 1. If you use lambdas on 2.18, you can't backport the code.
>>>>
>>>> 2. I'll spend some time this weekend installing the bundles on Karaf. Karaf
>>>> 4 is OK, or are we sticking with older versions for 2.x?
>>>>
>>>
>>> Karaf 2.x is dropped. Use Karaf 4.x as the primary karaf version.
>>> We may want to add a -Pkaraf3 profile to run against older Karaf 3.x containers.
>>>
>>>
>>>> 3. I'll also run our OSGi itests, but it may be worth having Jenkins do all
>>>> this. Could you configure a job in JKS to build this branch? I don't have
>>>> job admin rights I believe.
>>>>
>>>
>>> We already have some CI jobs to run 2 osgi based tests
>>>
>>> - tests/camel-itest-karaf
>>> - tests/camel-itest-osgi
>>>
>>> The former tests that the Camel component can be installed, it does
>>> this using pax-exam to bootup karaf and install the camel-xxx feature
>>> and find the component and then tear down the test.
>>>
>>> You can run these tests with the -Pkaraf4 profile.
>>> But mind I had trouble with these tests may stop after 20 or so tests
>>> and leave some karaf JVMs dangling. There is a kill-karaf.sh script to
>>> kill em.
>>>
>>> The camel-itest-osgi is likely in some state where some tests would
>>> fail even for older branches. But these are unit tests that run Camel
>>> apps in karaf and do some testing stuff like we do in regular
>>> component tests. This has not yet been migrated to karaf 4, and run on
>>> karaf 2.x. But you can give it a go and see how bad/good it is. It
>>> used to be able to run almost all tests and pass. And we had also had
>>> periods where everything was green.
>>>
>>> However people dont write so many osgi tests so this module do not
>>> have so much love. And there are plenty of components that are not
>>> being tested.
>>>
>>>
>>>> 4. It's necessary to configure the maven-jar-plugin to explicitly use a
>>>> manifest file, otherwise the plugin generates its own. Originally I tried
>>>> adding the config to the build plugins in the parent POM, but it failed for
>>>> artifacts of type=maven-plugin. Hence I placed it in pluginManagement and
>>>> then incorporated it in those intermediate POMs (components, examples,
>>>> etc.) whose children built normal JARs. However, I ended up tracing the
>>>> issue to a conflict introduced by the config of the maven-jar-plugin that
>>>> maven-plugin injects, and solved it with a couple
>>>> of combine.self="override". Hence, I think I might be able to push our
>>>> maven-jar-plugin config back to the parent POM and to the build section.
>>>>
>>>
>>> Ah okay. I am okay with we can do "anything" we need to build all the
>>> Camel components and whatnot.
>>>
>>> Its more what the impact is for end users. If we can make out examples
>>> and maven archetypes simpler and easier that would be cool. But mind
>>> that not all examples are osgi examples.
>>>
>>> But it looks promising your work - thanks for starting this hard work.
>>>
>>>
>>>
>>>> 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>
>>>>
>>>> On Sat, Mar 26, 2016 at 10:12 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>
>>>>> 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
>>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
I managed to get the CI jobs to complete now with setting higher memory.

The snapshots are now deployed and the CI jobs for osgi is triggered

Triggering a new build of Camel.trunk.itest.karaf
Triggering a new build of Camel.trunk.itest.osgi
Finished: SUCCESS



On Sat, Mar 26, 2016 at 12:36 PM, Claus Ibsen <cl...@gmail.com> wrote:
> Oh I forgot the CI jobs are here
> https://builds.apache.org/view/A-D/view/Camel/
>
> I got the link from Mueller. Beforehand it was hard/impossible to find
> Camel from
> https://builds.apache.org/
>
> So I was for a longer time not able to see all these jobs, and just
> got the CI emails to look at.
>
> But the OSGi jobs rely on the SNAPSHOT of Camel has been built prior
> to that, and that job is unreliable. I think we need to look at making
> the -notest also publish the SNAPSHOT to the snapshot mvn repo, so the
> CI jobs can pickup these new JARs.
>
> If we get that more reliable then Camel end users can also easier use
> SNAPSHOT instead of having to build locally to be sure they get a
> clean build of it, otherwise you can end up with mixed builds or
> stale/old snapshots.
>
>
>
> On Sat, Mar 26, 2016 at 12:33 PM, Claus Ibsen <cl...@gmail.com> wrote:
>> On Sat, Mar 26, 2016 at 12:12 PM, Raul Kripalani <ra...@apache.org> wrote:
>>> Agree with your points.
>>>
>>> 1. If you use lambdas on 2.18, you can't backport the code.
>>>
>>> 2. I'll spend some time this weekend installing the bundles on Karaf. Karaf
>>> 4 is OK, or are we sticking with older versions for 2.x?
>>>
>>
>> Karaf 2.x is dropped. Use Karaf 4.x as the primary karaf version.
>> We may want to add a -Pkaraf3 profile to run against older Karaf 3.x containers.
>>
>>
>>> 3. I'll also run our OSGi itests, but it may be worth having Jenkins do all
>>> this. Could you configure a job in JKS to build this branch? I don't have
>>> job admin rights I believe.
>>>
>>
>> We already have some CI jobs to run 2 osgi based tests
>>
>> - tests/camel-itest-karaf
>> - tests/camel-itest-osgi
>>
>> The former tests that the Camel component can be installed, it does
>> this using pax-exam to bootup karaf and install the camel-xxx feature
>> and find the component and then tear down the test.
>>
>> You can run these tests with the -Pkaraf4 profile.
>> But mind I had trouble with these tests may stop after 20 or so tests
>> and leave some karaf JVMs dangling. There is a kill-karaf.sh script to
>> kill em.
>>
>> The camel-itest-osgi is likely in some state where some tests would
>> fail even for older branches. But these are unit tests that run Camel
>> apps in karaf and do some testing stuff like we do in regular
>> component tests. This has not yet been migrated to karaf 4, and run on
>> karaf 2.x. But you can give it a go and see how bad/good it is. It
>> used to be able to run almost all tests and pass. And we had also had
>> periods where everything was green.
>>
>> However people dont write so many osgi tests so this module do not
>> have so much love. And there are plenty of components that are not
>> being tested.
>>
>>
>>> 4. It's necessary to configure the maven-jar-plugin to explicitly use a
>>> manifest file, otherwise the plugin generates its own. Originally I tried
>>> adding the config to the build plugins in the parent POM, but it failed for
>>> artifacts of type=maven-plugin. Hence I placed it in pluginManagement and
>>> then incorporated it in those intermediate POMs (components, examples,
>>> etc.) whose children built normal JARs. However, I ended up tracing the
>>> issue to a conflict introduced by the config of the maven-jar-plugin that
>>> maven-plugin injects, and solved it with a couple
>>> of combine.self="override". Hence, I think I might be able to push our
>>> maven-jar-plugin config back to the parent POM and to the build section.
>>>
>>
>> Ah okay. I am okay with we can do "anything" we need to build all the
>> Camel components and whatnot.
>>
>> Its more what the impact is for end users. If we can make out examples
>> and maven archetypes simpler and easier that would be cool. But mind
>> that not all examples are osgi examples.
>>
>> But it looks promising your work - thanks for starting this hard work.
>>
>>
>>
>>> 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>
>>>
>>> On Sat, Mar 26, 2016 at 10:12 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>
>>>> 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
>>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
Oh I forgot the CI jobs are here
https://builds.apache.org/view/A-D/view/Camel/

I got the link from Mueller. Beforehand it was hard/impossible to find
Camel from
https://builds.apache.org/

So I was for a longer time not able to see all these jobs, and just
got the CI emails to look at.

But the OSGi jobs rely on the SNAPSHOT of Camel has been built prior
to that, and that job is unreliable. I think we need to look at making
the -notest also publish the SNAPSHOT to the snapshot mvn repo, so the
CI jobs can pickup these new JARs.

If we get that more reliable then Camel end users can also easier use
SNAPSHOT instead of having to build locally to be sure they get a
clean build of it, otherwise you can end up with mixed builds or
stale/old snapshots.



On Sat, Mar 26, 2016 at 12:33 PM, Claus Ibsen <cl...@gmail.com> wrote:
> On Sat, Mar 26, 2016 at 12:12 PM, Raul Kripalani <ra...@apache.org> wrote:
>> Agree with your points.
>>
>> 1. If you use lambdas on 2.18, you can't backport the code.
>>
>> 2. I'll spend some time this weekend installing the bundles on Karaf. Karaf
>> 4 is OK, or are we sticking with older versions for 2.x?
>>
>
> Karaf 2.x is dropped. Use Karaf 4.x as the primary karaf version.
> We may want to add a -Pkaraf3 profile to run against older Karaf 3.x containers.
>
>
>> 3. I'll also run our OSGi itests, but it may be worth having Jenkins do all
>> this. Could you configure a job in JKS to build this branch? I don't have
>> job admin rights I believe.
>>
>
> We already have some CI jobs to run 2 osgi based tests
>
> - tests/camel-itest-karaf
> - tests/camel-itest-osgi
>
> The former tests that the Camel component can be installed, it does
> this using pax-exam to bootup karaf and install the camel-xxx feature
> and find the component and then tear down the test.
>
> You can run these tests with the -Pkaraf4 profile.
> But mind I had trouble with these tests may stop after 20 or so tests
> and leave some karaf JVMs dangling. There is a kill-karaf.sh script to
> kill em.
>
> The camel-itest-osgi is likely in some state where some tests would
> fail even for older branches. But these are unit tests that run Camel
> apps in karaf and do some testing stuff like we do in regular
> component tests. This has not yet been migrated to karaf 4, and run on
> karaf 2.x. But you can give it a go and see how bad/good it is. It
> used to be able to run almost all tests and pass. And we had also had
> periods where everything was green.
>
> However people dont write so many osgi tests so this module do not
> have so much love. And there are plenty of components that are not
> being tested.
>
>
>> 4. It's necessary to configure the maven-jar-plugin to explicitly use a
>> manifest file, otherwise the plugin generates its own. Originally I tried
>> adding the config to the build plugins in the parent POM, but it failed for
>> artifacts of type=maven-plugin. Hence I placed it in pluginManagement and
>> then incorporated it in those intermediate POMs (components, examples,
>> etc.) whose children built normal JARs. However, I ended up tracing the
>> issue to a conflict introduced by the config of the maven-jar-plugin that
>> maven-plugin injects, and solved it with a couple
>> of combine.self="override". Hence, I think I might be able to push our
>> maven-jar-plugin config back to the parent POM and to the build section.
>>
>
> Ah okay. I am okay with we can do "anything" we need to build all the
> Camel components and whatnot.
>
> Its more what the impact is for end users. If we can make out examples
> and maven archetypes simpler and easier that would be cool. But mind
> that not all examples are osgi examples.
>
> But it looks promising your work - thanks for starting this hard work.
>
>
>
>> 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>
>>
>> On Sat, Mar 26, 2016 at 10:12 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>
>>> 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
>>>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Mar 26, 2016 at 12:12 PM, Raul Kripalani <ra...@apache.org> wrote:
> Agree with your points.
>
> 1. If you use lambdas on 2.18, you can't backport the code.
>
> 2. I'll spend some time this weekend installing the bundles on Karaf. Karaf
> 4 is OK, or are we sticking with older versions for 2.x?
>

Karaf 2.x is dropped. Use Karaf 4.x as the primary karaf version.
We may want to add a -Pkaraf3 profile to run against older Karaf 3.x containers.


> 3. I'll also run our OSGi itests, but it may be worth having Jenkins do all
> this. Could you configure a job in JKS to build this branch? I don't have
> job admin rights I believe.
>

We already have some CI jobs to run 2 osgi based tests

- tests/camel-itest-karaf
- tests/camel-itest-osgi

The former tests that the Camel component can be installed, it does
this using pax-exam to bootup karaf and install the camel-xxx feature
and find the component and then tear down the test.

You can run these tests with the -Pkaraf4 profile.
But mind I had trouble with these tests may stop after 20 or so tests
and leave some karaf JVMs dangling. There is a kill-karaf.sh script to
kill em.

The camel-itest-osgi is likely in some state where some tests would
fail even for older branches. But these are unit tests that run Camel
apps in karaf and do some testing stuff like we do in regular
component tests. This has not yet been migrated to karaf 4, and run on
karaf 2.x. But you can give it a go and see how bad/good it is. It
used to be able to run almost all tests and pass. And we had also had
periods where everything was green.

However people dont write so many osgi tests so this module do not
have so much love. And there are plenty of components that are not
being tested.


> 4. It's necessary to configure the maven-jar-plugin to explicitly use a
> manifest file, otherwise the plugin generates its own. Originally I tried
> adding the config to the build plugins in the parent POM, but it failed for
> artifacts of type=maven-plugin. Hence I placed it in pluginManagement and
> then incorporated it in those intermediate POMs (components, examples,
> etc.) whose children built normal JARs. However, I ended up tracing the
> issue to a conflict introduced by the config of the maven-jar-plugin that
> maven-plugin injects, and solved it with a couple
> of combine.self="override". Hence, I think I might be able to push our
> maven-jar-plugin config back to the parent POM and to the build section.
>

Ah okay. I am okay with we can do "anything" we need to build all the
Camel components and whatnot.

Its more what the impact is for end users. If we can make out examples
and maven archetypes simpler and easier that would be cool. But mind
that not all examples are osgi examples.

But it looks promising your work - thanks for starting this hard work.



> 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>
>
> On Sat, Mar 26, 2016 at 10:12 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> 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
>>



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Raul Kripalani <ra...@apache.org>.
Agree with your points.

1. If you use lambdas on 2.18, you can't backport the code.

2. I'll spend some time this weekend installing the bundles on Karaf. Karaf
4 is OK, or are we sticking with older versions for 2.x?

3. I'll also run our OSGi itests, but it may be worth having Jenkins do all
this. Could you configure a job in JKS to build this branch? I don't have
job admin rights I believe.

4. It's necessary to configure the maven-jar-plugin to explicitly use a
manifest file, otherwise the plugin generates its own. Originally I tried
adding the config to the build plugins in the parent POM, but it failed for
artifacts of type=maven-plugin. Hence I placed it in pluginManagement and
then incorporated it in those intermediate POMs (components, examples,
etc.) whose children built normal JARs. However, I ended up tracing the
issue to a conflict introduced by the config of the maven-jar-plugin that
maven-plugin injects, and solved it with a couple
of combine.self="override". Hence, I think I might be able to push our
maven-jar-plugin config back to the parent POM and to the build section.

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>

On Sat, Mar 26, 2016 at 10:12 AM, Claus Ibsen <cl...@gmail.com> wrote:

> 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
>

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Mar 26, 2016 at 11:55 AM, Krzysztof Sobkowiak
<kr...@gmail.com> wrote:
> Hi
>
> Probably it makes sense to write simple itest for each module which only install the module (and dependencies)
> into the Karaf container. We would have simple smoke tests for all modules.
>

Yes we already got that in the tests/camel-itest-karaf.

You can run them with -Pkaraf4 as they still use karaf 2.x by default.

But as I have said they tend to stop after a while and leave karaf
JVMs dangling.
So if anyone fancy take a look and try to make this more stable that
would be cool.


> Regards
> Krzysztof
>
> On 26.03.2016 11:12, Claus Ibsen wrote:
>> 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.
>
> --
> Krzysztof Sobkowiak (@ksobkowiak)
>
> JEE & OSS Architect, Integration Architect
> Apache Software Foundation Member (http://apache.org/)
> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
> Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
Hi

Probably it makes sense to write simple itest for each module which only install the module (and dependencies)
into the Karaf container. We would have simple smoke tests for all modules.

Regards
Krzysztof

On 26.03.2016 11:12, Claus Ibsen wrote:
> 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.

-- 
Krzysztof Sobkowiak (@ksobkowiak)

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)

Posted by Claus Ibsen <cl...@gmail.com>.
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