[DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Claus Ibsen-2
Hi Antoine

Yay sounds good. What do you fancy working with?

We got stuff around OSGi such as

- upgrading the tests to be karaf 4.x based
- drop karaf 2.x
- upgrade to OSGi 5.0

Some easier ones would be in the platforms/karaf/features to make
karaf 4 the default being used in the validation, currently its 2.x.
And likewise in the tests/camel-itest-karaf.

For non OSGi stuff then one of the most hard ones is to migrate two
components to Jetty 9. I think its camel-cometd and camel-websocket.

There is also an easier one to upgrade jetty 9.2 -> 9.3.

And then there is also the component docs to create adoc files. Andrea
knows how to do that, so he can tell the procedure. There is a way you
can export from wiki and then manually need to do some adjustments.

Then there is the splitup of camel-cxf into smaller components to
separate it from ws/rs and spring/blueprint etc.

And there is also Raul's branch with the change in the build system
for lambda compilation that affects all OSGi. So it need rigorous OSGi
testing before it can be merged. See other email in this @dev.

And there is JIRA with the 2.18 tickets
https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.18.0%20AND%20project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20DESC











On Fri, Mar 25, 2016 at 6:47 PM, Antoine Toulme <[hidden email]> wrote:

> I’d like to help for this release. Looks like you got a good laundry list already. Where can I help best in that list?
>
>
>> On Mar 23, 2016, at 3:07 AM, Claus Ibsen <[hidden email]> wrote:
>>
>> Hi
>>
>> So Camel 2.17 was the last release supporting Java 1.7.
>> The next Camel 2.18 is requiring Java 1.8.
>>
>> Here is some thoughts of mine about this release up for discussion.
>>
>>
>>
>> a)
>> I see the overall goal of Camel 2.18 as a stepping stone towards Java
>> 1.8 and Camel 3.0.
>>
>> By that I mean the release should be a way of moving our existing
>> users from Java 1.7 and the current Camel APIs and the likes gradually
>> towards Java 1.8 and eventually Camel 3.0.
>>
>> In other words we should not get carried away to change/break APIs and
>> whatnot just because Java 1.8 lambdas and functions.
>>
>> There are too many current users that rely on the current Camel API
>> and we cannot go around change processor / expression / predicate /
>> aggregation strategy and other interfaces to be java 8 functional if
>> that means current code cannot compile. And certainly not adding
>> Optional<X> as return types all over.
>>
>> The following releases (Camel 2.19 or 3.0) can pick up that torch and
>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>> changes that are Java 8 lambda / functional based. And as well changes
>> in the DSL to go with that.
>>
>> There are some minor code changes needed to make the source compile as
>> source 1.8 to go in this Camel 2.18 let alone.
>>
>>
>> b)
>> Drop components that do not support and run on Java 1.8
>> And potentially remove some deprecated components
>>
>>
>> c)
>> Drop karaf 2.x.
>> And move to karaf 4.x for all our testing.
>>
>>
>> d)
>> Drop Jetty 8.x.
>>
>> This also requires to upgrade at least two components that currently
>> rely on Jetty 8 to use Jetty 9.
>>
>>
>> e)
>> Upgrade to latest Jetty 9.
>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>
>>
>> f)
>> Drop support for older versions of Spring. We have a number of
>> camel-test-spring3 etc modules that can be dropped. And maybe even
>> spring 4.0. as its also EOL.
>>
>>
>> g)
>> Potentially move spring-dm out of camel-spring into a camel-spring-dm
>> module. So camel-spring can use latest version of Spring safely. This
>> also makes it easier to deprecated spring-dm and remove it eventually.
>> The Karaf team is working on a sping -> blueprint layer so you can use
>> spring xml files but Karaf will "convert" that under the hood to
>> blueprint and run it as blueprint. When that is ready we no longer
>> need spring-dm.
>>
>>
>> h)
>> Continue adding components docs in the source, eg src/main/doc files.
>> So we eventually have as many/all of them. This is an ongoing effort,
>> as we need to do this for the EIPs and the other parts of the docs.
>>
>> However I see this as a great step for a new documentation and
>> website, that IMHO is a big goal for Camel 3.0. To make the project
>> website fresh and modern. And make the documentation easier for end
>> users to use and view.
>>
>>
>> i)
>> Add camel-hysterix component and integrate camel's circuit breaker
>> into turbine/hysterix so you can see metrics from camel in the
>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>
>>
>> j)
>> Split camel-cxf into modules so we can separate WS and RS and also
>> spring vs blueprint. Today its big ball of dependencies that is a bit
>> hard to slice and dice. Specially for MSA style with REST and you dont
>> want to add in a bunch of extra not needed JARs.
>>
>>
>> k)
>> Continue as usual by adding new components, data formats, fix bugs, and so on.
>>
>>
>> l)
>> Timeline. This release do not need to have 6-8 months timeframe. We
>> could try to get this "stepping stone" release done sooner, so it can
>> be released during/shortly after summer.
>>
>> There is plenty of "first work" that we must do with the java 8
>> upgrade and dropping older techs etc, that we have our hands full for
>> a while.
>>
>> Doing a release with these changes allows our end users to migrate
>> along in a easy way, than a big bang - breaking apis - release would
>> do. And the latter would be more appropriate to be released as Camel
>> 3.0.
>>
>> Then towards the end of this year, we can see where we are and plan
>> for a Camel 3.0 with a new website and documentation that such a
>> release deserve. For example if we release Camel 3.0 in start of 2017
>> then its also Camel's 10 year birthday year.
>>
>> And doing such a release with a rewamped website with fresh looking
>> documentation and content, is what helps the project a lot.
>>
>> The current website looks the same as it did when it was created:
>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>
>> PS: We surely also need a better "what is Camel" story on the front
>> page. Its still that very first one with all the tech jumble that was
>> initially created.
>>
>> PPS: I would also love to see a new Camel logo. The current one is a
>> bit dull and boring.
>>
>>
>>
>>
>> --
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Claus Ibsen-2
In reply to this post by Claus Ibsen-2
Hi

There was a comment on my blog about the Camel logo


Hey Claus; The OpenTSDB project (http://opentsdb.net/) ran an icon
design contest on 99designs. People submit designs and others vote.
It's a cool system and I imagine you would get a lot of
submissions....



On Wed, Mar 23, 2016 at 11:07 AM, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> So Camel 2.17 was the last release supporting Java 1.7.
> The next Camel 2.18 is requiring Java 1.8.
>
> Here is some thoughts of mine about this release up for discussion.
>
>
>
> a)
> I see the overall goal of Camel 2.18 as a stepping stone towards Java
> 1.8 and Camel 3.0.
>
> By that I mean the release should be a way of moving our existing
> users from Java 1.7 and the current Camel APIs and the likes gradually
> towards Java 1.8 and eventually Camel 3.0.
>
> In other words we should not get carried away to change/break APIs and
> whatnot just because Java 1.8 lambdas and functions.
>
> There are too many current users that rely on the current Camel API
> and we cannot go around change processor / expression / predicate /
> aggregation strategy and other interfaces to be java 8 functional if
> that means current code cannot compile. And certainly not adding
> Optional<X> as return types all over.
>
> The following releases (Camel 2.19 or 3.0) can pick up that torch and
> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
> changes that are Java 8 lambda / functional based. And as well changes
> in the DSL to go with that.
>
> There are some minor code changes needed to make the source compile as
> source 1.8 to go in this Camel 2.18 let alone.
>
>
> b)
> Drop components that do not support and run on Java 1.8
> And potentially remove some deprecated components
>
>
> c)
> Drop karaf 2.x.
> And move to karaf 4.x for all our testing.
>
>
> d)
> Drop Jetty 8.x.
>
> This also requires to upgrade at least two components that currently
> rely on Jetty 8 to use Jetty 9.
>
>
> e)
> Upgrade to latest Jetty 9.
> Jetty 9.3 (or is it 9.4) requires Java 1.8
>
>
> f)
> Drop support for older versions of Spring. We have a number of
> camel-test-spring3 etc modules that can be dropped. And maybe even
> spring 4.0. as its also EOL.
>
>
> g)
> Potentially move spring-dm out of camel-spring into a camel-spring-dm
> module. So camel-spring can use latest version of Spring safely. This
> also makes it easier to deprecated spring-dm and remove it eventually.
> The Karaf team is working on a sping -> blueprint layer so you can use
> spring xml files but Karaf will "convert" that under the hood to
> blueprint and run it as blueprint. When that is ready we no longer
> need spring-dm.
>
>
> h)
> Continue adding components docs in the source, eg src/main/doc files.
> So we eventually have as many/all of them. This is an ongoing effort,
> as we need to do this for the EIPs and the other parts of the docs.
>
> However I see this as a great step for a new documentation and
> website, that IMHO is a big goal for Camel 3.0. To make the project
> website fresh and modern. And make the documentation easier for end
> users to use and view.
>
>
> i)
> Add camel-hysterix component and integrate camel's circuit breaker
> into turbine/hysterix so you can see metrics from camel in the
> dashboard. Eg to integrate with the popular Netflix OSS stack.
>
>
> j)
> Split camel-cxf into modules so we can separate WS and RS and also
> spring vs blueprint. Today its big ball of dependencies that is a bit
> hard to slice and dice. Specially for MSA style with REST and you dont
> want to add in a bunch of extra not needed JARs.
>
>
> k)
> Continue as usual by adding new components, data formats, fix bugs, and so on.
>
>
> l)
> Timeline. This release do not need to have 6-8 months timeframe. We
> could try to get this "stepping stone" release done sooner, so it can
> be released during/shortly after summer.
>
> There is plenty of "first work" that we must do with the java 8
> upgrade and dropping older techs etc, that we have our hands full for
> a while.
>
> Doing a release with these changes allows our end users to migrate
> along in a easy way, than a big bang - breaking apis - release would
> do. And the latter would be more appropriate to be released as Camel
> 3.0.
>
> Then towards the end of this year, we can see where we are and plan
> for a Camel 3.0 with a new website and documentation that such a
> release deserve. For example if we release Camel 3.0 in start of 2017
> then its also Camel's 10 year birthday year.
>
> And doing such a release with a rewamped website with fresh looking
> documentation and content, is what helps the project a lot.
>
> The current website looks the same as it did when it was created:
> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>
> PS: We surely also need a better "what is Camel" story on the front
> page. Its still that very first one with all the tech jumble that was
> initially created.
>
> PPS: I would also love to see a new Camel logo. The current one is a
> bit dull and boring.
>
>
>
>
> --
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Antoine Toulme-2
In reply to this post by Claus Ibsen-2

> On Mar 25, 2016, at 10:42 PM, Claus Ibsen <[hidden email]> wrote:
>
> Hi Antoine
>
> Yay sounds good. What do you fancy working with?
>
> We got stuff around OSGi such as
>
> - upgrading the tests to be karaf 4.x based
> - drop karaf 2.x
> - upgrade to OSGi 5.0
Looks like Raul is on top of it. I have some OSGi experience.
>
> Some easier ones would be in the platforms/karaf/features to make
> karaf 4 the default being used in the validation, currently its 2.x.
> And likewise in the tests/camel-itest-karaf.
Easy enough. Will take a look.
>
> For non OSGi stuff then one of the most hard ones is to migrate two
> components to Jetty 9. I think its camel-cometd and camel-websocket.
I would do those first. I have some experience dealing with Jetty.
>
> There is also an easier one to upgrade jetty 9.2 -> 9.3.
>
> And then there is also the component docs to create adoc files. Andrea
> knows how to do that, so he can tell the procedure. There is a way you
> can export from wiki and then manually need to do some adjustments.
I can at least do dns and jackson-xml.

>
> Then there is the splitup of camel-cxf into smaller components to
> separate it from ws/rs and spring/blueprint etc.
>
> And there is also Raul's branch with the change in the build system
> for lambda compilation that affects all OSGi. So it need rigorous OSGi
> testing before it can be merged. See other email in this @dev.
>
> And there is JIRA with the 2.18 tickets
> https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.18.0%20AND%20project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20DESC
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Mar 25, 2016 at 6:47 PM, Antoine Toulme <[hidden email]> wrote:
>> I’d like to help for this release. Looks like you got a good laundry list already. Where can I help best in that list?
>>
>>
>>> On Mar 23, 2016, at 3:07 AM, Claus Ibsen <[hidden email]> wrote:
>>>
>>> Hi
>>>
>>> So Camel 2.17 was the last release supporting Java 1.7.
>>> The next Camel 2.18 is requiring Java 1.8.
>>>
>>> Here is some thoughts of mine about this release up for discussion.
>>>
>>>
>>>
>>> a)
>>> I see the overall goal of Camel 2.18 as a stepping stone towards Java
>>> 1.8 and Camel 3.0.
>>>
>>> By that I mean the release should be a way of moving our existing
>>> users from Java 1.7 and the current Camel APIs and the likes gradually
>>> towards Java 1.8 and eventually Camel 3.0.
>>>
>>> In other words we should not get carried away to change/break APIs and
>>> whatnot just because Java 1.8 lambdas and functions.
>>>
>>> There are too many current users that rely on the current Camel API
>>> and we cannot go around change processor / expression / predicate /
>>> aggregation strategy and other interfaces to be java 8 functional if
>>> that means current code cannot compile. And certainly not adding
>>> Optional<X> as return types all over.
>>>
>>> The following releases (Camel 2.19 or 3.0) can pick up that torch and
>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>> changes that are Java 8 lambda / functional based. And as well changes
>>> in the DSL to go with that.
>>>
>>> There are some minor code changes needed to make the source compile as
>>> source 1.8 to go in this Camel 2.18 let alone.
>>>
>>>
>>> b)
>>> Drop components that do not support and run on Java 1.8
>>> And potentially remove some deprecated components
>>>
>>>
>>> c)
>>> Drop karaf 2.x.
>>> And move to karaf 4.x for all our testing.
>>>
>>>
>>> d)
>>> Drop Jetty 8.x.
>>>
>>> This also requires to upgrade at least two components that currently
>>> rely on Jetty 8 to use Jetty 9.
>>>
>>>
>>> e)
>>> Upgrade to latest Jetty 9.
>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>
>>>
>>> f)
>>> Drop support for older versions of Spring. We have a number of
>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>> spring 4.0. as its also EOL.
>>>
>>>
>>> g)
>>> Potentially move spring-dm out of camel-spring into a camel-spring-dm
>>> module. So camel-spring can use latest version of Spring safely. This
>>> also makes it easier to deprecated spring-dm and remove it eventually.
>>> The Karaf team is working on a sping -> blueprint layer so you can use
>>> spring xml files but Karaf will "convert" that under the hood to
>>> blueprint and run it as blueprint. When that is ready we no longer
>>> need spring-dm.
>>>
>>>
>>> h)
>>> Continue adding components docs in the source, eg src/main/doc files.
>>> So we eventually have as many/all of them. This is an ongoing effort,
>>> as we need to do this for the EIPs and the other parts of the docs.
>>>
>>> However I see this as a great step for a new documentation and
>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>> website fresh and modern. And make the documentation easier for end
>>> users to use and view.
>>>
>>>
>>> i)
>>> Add camel-hysterix component and integrate camel's circuit breaker
>>> into turbine/hysterix so you can see metrics from camel in the
>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>
>>>
>>> j)
>>> Split camel-cxf into modules so we can separate WS and RS and also
>>> spring vs blueprint. Today its big ball of dependencies that is a bit
>>> hard to slice and dice. Specially for MSA style with REST and you dont
>>> want to add in a bunch of extra not needed JARs.
>>>
>>>
>>> k)
>>> Continue as usual by adding new components, data formats, fix bugs, and so on.
>>>
>>>
>>> l)
>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>> could try to get this "stepping stone" release done sooner, so it can
>>> be released during/shortly after summer.
>>>
>>> There is plenty of "first work" that we must do with the java 8
>>> upgrade and dropping older techs etc, that we have our hands full for
>>> a while.
>>>
>>> Doing a release with these changes allows our end users to migrate
>>> along in a easy way, than a big bang - breaking apis - release would
>>> do. And the latter would be more appropriate to be released as Camel
>>> 3.0.
>>>
>>> Then towards the end of this year, we can see where we are and plan
>>> for a Camel 3.0 with a new website and documentation that such a
>>> release deserve. For example if we release Camel 3.0 in start of 2017
>>> then its also Camel's 10 year birthday year.
>>>
>>> And doing such a release with a rewamped website with fresh looking
>>> documentation and content, is what helps the project a lot.
>>>
>>> The current website looks the same as it did when it was created:
>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>
>>> PS: We surely also need a better "what is Camel" story on the front
>>> page. Its still that very first one with all the tech jumble that was
>>> initially created.
>>>
>>> PPS: I would also love to see a new Camel logo. The current one is a
>>> bit dull and boring.
>>>
>>>
>>>
>>>
>>> --
>>> 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


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Jean-Baptiste Onofré
In reply to this post by Claus Ibsen-2

   
Hi guys
I have some stuff ready around Karaf 4 and OSGI 5/6 support.
I will share asap.
RegardsJB 


-------- Original message --------
From: Antoine Toulme <[hidden email]>
Date: 29/03/2016  08:36  (GMT+01:00)
To: [hidden email]
Subject: Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0


> On Mar 25, 2016, at 10:42 PM, Claus Ibsen <[hidden email]> wrote:
>
> Hi Antoine
>
> Yay sounds good. What do you fancy working with?
>
> We got stuff around OSGi such as
>
> - upgrading the tests to be karaf 4.x based
> - drop karaf 2.x
> - upgrade to OSGi 5.0
Looks like Raul is on top of it. I have some OSGi experience.
>
> Some easier ones would be in the platforms/karaf/features to make
> karaf 4 the default being used in the validation, currently its 2.x.
> And likewise in the tests/camel-itest-karaf.
Easy enough. Will take a look.
>
> For non OSGi stuff then one of the most hard ones is to migrate two
> components to Jetty 9. I think its camel-cometd and camel-websocket.
I would do those first. I have some experience dealing with Jetty.
>
> There is also an easier one to upgrade jetty 9.2 -> 9.3.
>
> And then there is also the component docs to create adoc files. Andrea
> knows how to do that, so he can tell the procedure. There is a way you
> can export from wiki and then manually need to do some adjustments.
I can at least do dns and jackson-xml.

>
> Then there is the splitup of camel-cxf into smaller components to
> separate it from ws/rs and spring/blueprint etc.
>
> And there is also Raul's branch with the change in the build system
> for lambda compilation that affects all OSGi. So it need rigorous OSGi
> testing before it can be merged. See other email in this @dev.
>
> And there is JIRA with the 2.18 tickets
> https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.18.0%20AND%20project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20DESC
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Mar 25, 2016 at 6:47 PM, Antoine Toulme <[hidden email]> wrote:
>> I’d like to help for this release. Looks like you got a good laundry list already. Where can I help best in that list?
>>
>>
>>> On Mar 23, 2016, at 3:07 AM, Claus Ibsen <[hidden email]> wrote:
>>>
>>> Hi
>>>
>>> So Camel 2.17 was the last release supporting Java 1.7.
>>> The next Camel 2.18 is requiring Java 1.8.
>>>
>>> Here is some thoughts of mine about this release up for discussion.
>>>
>>>
>>>
>>> a)
>>> I see the overall goal of Camel 2.18 as a stepping stone towards Java
>>> 1.8 and Camel 3.0.
>>>
>>> By that I mean the release should be a way of moving our existing
>>> users from Java 1.7 and the current Camel APIs and the likes gradually
>>> towards Java 1.8 and eventually Camel 3.0.
>>>
>>> In other words we should not get carried away to change/break APIs and
>>> whatnot just because Java 1.8 lambdas and functions.
>>>
>>> There are too many current users that rely on the current Camel API
>>> and we cannot go around change processor / expression / predicate /
>>> aggregation strategy and other interfaces to be java 8 functional if
>>> that means current code cannot compile. And certainly not adding
>>> Optional<X> as return types all over.
>>>
>>> The following releases (Camel 2.19 or 3.0) can pick up that torch and
>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>> changes that are Java 8 lambda / functional based. And as well changes
>>> in the DSL to go with that.
>>>
>>> There are some minor code changes needed to make the source compile as
>>> source 1.8 to go in this Camel 2.18 let alone.
>>>
>>>
>>> b)
>>> Drop components that do not support and run on Java 1.8
>>> And potentially remove some deprecated components
>>>
>>>
>>> c)
>>> Drop karaf 2.x.
>>> And move to karaf 4.x for all our testing.
>>>
>>>
>>> d)
>>> Drop Jetty 8.x.
>>>
>>> This also requires to upgrade at least two components that currently
>>> rely on Jetty 8 to use Jetty 9.
>>>
>>>
>>> e)
>>> Upgrade to latest Jetty 9.
>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>
>>>
>>> f)
>>> Drop support for older versions of Spring. We have a number of
>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>> spring 4.0. as its also EOL.
>>>
>>>
>>> g)
>>> Potentially move spring-dm out of camel-spring into a camel-spring-dm
>>> module. So camel-spring can use latest version of Spring safely. This
>>> also makes it easier to deprecated spring-dm and remove it eventually.
>>> The Karaf team is working on a sping -> blueprint layer so you can use
>>> spring xml files but Karaf will "convert" that under the hood to
>>> blueprint and run it as blueprint. When that is ready we no longer
>>> need spring-dm.
>>>
>>>
>>> h)
>>> Continue adding components docs in the source, eg src/main/doc files.
>>> So we eventually have as many/all of them. This is an ongoing effort,
>>> as we need to do this for the EIPs and the other parts of the docs.
>>>
>>> However I see this as a great step for a new documentation and
>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>> website fresh and modern. And make the documentation easier for end
>>> users to use and view.
>>>
>>>
>>> i)
>>> Add camel-hysterix component and integrate camel's circuit breaker
>>> into turbine/hysterix so you can see metrics from camel in the
>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>
>>>
>>> j)
>>> Split camel-cxf into modules so we can separate WS and RS and also
>>> spring vs blueprint. Today its big ball of dependencies that is a bit
>>> hard to slice and dice. Specially for MSA style with REST and you dont
>>> want to add in a bunch of extra not needed JARs.
>>>
>>>
>>> k)
>>> Continue as usual by adding new components, data formats, fix bugs, and so on.
>>>
>>>
>>> l)
>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>> could try to get this "stepping stone" release done sooner, so it can
>>> be released during/shortly after summer.
>>>
>>> There is plenty of "first work" that we must do with the java 8
>>> upgrade and dropping older techs etc, that we have our hands full for
>>> a while.
>>>
>>> Doing a release with these changes allows our end users to migrate
>>> along in a easy way, than a big bang - breaking apis - release would
>>> do. And the latter would be more appropriate to be released as Camel
>>> 3.0.
>>>
>>> Then towards the end of this year, we can see where we are and plan
>>> for a Camel 3.0 with a new website and documentation that such a
>>> release deserve. For example if we release Camel 3.0 in start of 2017
>>> then its also Camel's 10 year birthday year.
>>>
>>> And doing such a release with a rewamped website with fresh looking
>>> documentation and content, is what helps the project a lot.
>>>
>>> The current website looks the same as it did when it was created:
>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>
>>> PS: We surely also need a better "what is Camel" story on the front
>>> page. Its still that very first one with all the tech jumble that was
>>> initially created.
>>>
>>> PPS: I would also love to see a new Camel logo. The current one is a
>>> bit dull and boring.
>>>
>>>
>>>
>>>
>>> --
>>> 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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Christian Schneider
In reply to this post by Claus Ibsen-2
I recently worked on some projects that also need OSGi settings and
found an interesting thing.
It seems the easiest way to get the exports, imports and other OSGi
settings right is not to use central defaults and instead do all
settings per project while relying on defaults as much as possible.

I use these settings in the parent:
https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L199-L223

So basically what I do is to only activate the bundle plugin in the
parent and set it to not auto export packages. For bnd-maven-plugin this
should not be necessary as it is the default.
I then delegate the OSGi settings to a bnd.bnd file. This is largely
equal to the pom config but a little less verbose.

An example can be found at:
https://github.com/apache/aries-rsa/tree/master/rsa
https://github.com/apache/aries-rsa/blob/master/rsa/bnd.bnd

As you see the pom of each project contains no OSGi informations at all
and the bnd.bnd files are very small.
So I would recommend this approach for camel too.

Christian

On 24.03.2016 16:18, Claus Ibsen wrote:

> On Thu, Mar 24, 2016 at 4:10 PM, Quinn Stevenson
> <[hidden email]> wrote:
>> I’d be happy to take a shot at the conversion.  Is there an appropriate JIRA created already?  Or should I continue what you started on the osgi-trouble branch?
>>
> I suggest to start a new branch. The osgi-trouble branch includes
> another upgrade as well that surfaced a bug in the old felix
> bundle-plugin. If we get the osgi fixed then we can cherry-pick the
> caffiene upgrade that are in this branch also.
>
> The new branch could try to aim at
>
> - try to use the bnd plugin
> - if that fails try to upgrade to newer felix plugin
> - upgrade to newer osgi (is that version 5.0 ?)
> - there is some default osgi imports in the parent pom.xml that likely
> need upgrades (i think its in the parent pom)
>
> And a related project is to upgrade the osgi tests in the tests
> directory to use karaf 4.x by default.
>
>
>
>
>>> On Mar 24, 2016, at 8:37 AM, Claus Ibsen <[hidden email]> wrote:
>>>
>>> Hi
>>>
>>> Thanks for sharing the details about the bnd maven plugin. Sounds
>>> promising if its more active maintained and is better.
>>>
>>> Anyone is surely welcome to give it a go on the Camel master branch.
>>> The build system is a bit complicated as there is some default stuff
>>> in parent pom.xml and some ant magic to "massage" maven vs osgi
>>> versions when using SNAPSHOTs and whatnot. Its all part of some old
>>> stuff we needed many years ago when OSGi was new and more buggy.
>>>
>>> I am not so sure we need all that anymore, it would be lovely to make
>>> the build system simpler and easier.
>>>
>>> Sadly I have not seen any tools that can compare a set of JARs against
>>> other JARs to see if their MANIFEST.MF is "the same". Its a bit scary
>>> if the new plugin generates "wrong" imports/exports and the only way
>>> to be sure it works is to run it all in a real osgi container and try
>>> all the components for real. Not only just see if the component can be
>>> installed.
>>>
>>> But then this is what the community is for - to help test - especially
>>> for the people who are using OSGi.
>>> People who are not, you are missing out all the fun ;) ..... or maybe not.
>>>
>>> A fallback plan is to keep using the old 2.3.7 plugin and then maybe
>>> "hand craft" the camel-core pom.xml instead of generating it to
>>> workaround its issue with Java 1.8 and the caffeine cache. But then we
>>> are stuck on this old dead horse still.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 24, 2016 at 2:47 PM, Quinn Stevenson
>>> <[hidden email]> wrote:
>>>> Antonin/Claus -
>>>>
>>>> I’ve used the bnd-maven-plugin, and it dramatically reduced the amount of configuration I had to do for my bundles.  I hit a bug in maven-bundle-plugin (https://issues.apache.org/jira/browse/FELIX-5179) and moving to the bnd-maven-plugin allowed me to what I needed to do.  I even provided a patch for the maven-bundle-plugin, but it has yet to be applied.
>>>>
>>>> I haven’t explored the intricacies of the Camel build as far as bundle manifests are concerned, but I think it would be worthwhile to try the bnd-maven-plugin.
>>>>
>>>>
>>>>> On Mar 24, 2016, at 2:28 AM, Antonin Stefanutti <[hidden email]> wrote:
>>>>>
>>>>> Hi Claus,
>>>>>
>>>>> Just in case for info, there is apparently a new BND Maven plugin [1] that is supposed to alleviate some of the issues encountered with maven-bundle-plugin.
>>>>>
>>>>> I haven’t tried it (nor am knowledgeable in the area) but that may be good to know at some point for that piece of work.
>>>>>
>>>>> [1]: http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html
>>>>>
>>>>> Antonin
>>>>>
>>>>>> On 24 Mar 2016, at 07:44, Claus Ibsen <[hidden email]> wrote:
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> m)
>>>>>> Upgrade OSGi
>>>>>>
>>>>>> We are using osgi 4.3.1 version which whatever OSGi version that is.
>>>>>> But there is a OSGi 5.0 that newer Karaf containers uses.
>>>>>>
>>>>>> But the big pain is upgrading maven-bundle-plugin. We are currently
>>>>>> using an old 2.3.7. But the newer versions have their new sets of
>>>>>> problems / fixes.
>>>>>>
>>>>>> i have struggled with newer versions generating missing details in the
>>>>>> manifest.mf files. For example camel-core did not export all its
>>>>>> packages etc. A bit scary. But we do have a fair bit of maven
>>>>>> properties and other osgi "magic" to make the build process build OSGi
>>>>>> modules across all the 250 or so artifacts.
>>>>>>
>>>>>> I pushed to a branch called osgi-trouble where you can see some of this problems
>>>>>> https://github.com/apache/camel/commits/osgi-trouble
>>>>>>
>>>>>> Using the latest 3.0.1 bundle plugin fails to build camel-core. It
>>>>>> complains something about the osgi activator.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 23, 2016 at 11:07 AM, Claus Ibsen <[hidden email]> wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> So Camel 2.17 was the last release supporting Java 1.7.
>>>>>>> The next Camel 2.18 is requiring Java 1.8.
>>>>>>>
>>>>>>> Here is some thoughts of mine about this release up for discussion.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> a)
>>>>>>> I see the overall goal of Camel 2.18 as a stepping stone towards Java
>>>>>>> 1.8 and Camel 3.0.
>>>>>>>
>>>>>>> By that I mean the release should be a way of moving our existing
>>>>>>> users from Java 1.7 and the current Camel APIs and the likes gradually
>>>>>>> towards Java 1.8 and eventually Camel 3.0.
>>>>>>>
>>>>>>> In other words we should not get carried away to change/break APIs and
>>>>>>> whatnot just because Java 1.8 lambdas and functions.
>>>>>>>
>>>>>>> There are too many current users that rely on the current Camel API
>>>>>>> and we cannot go around change processor / expression / predicate /
>>>>>>> aggregation strategy and other interfaces to be java 8 functional if
>>>>>>> that means current code cannot compile. And certainly not adding
>>>>>>> Optional<X> as return types all over.
>>>>>>>
>>>>>>> The following releases (Camel 2.19 or 3.0) can pick up that torch and
>>>>>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>>>>>> changes that are Java 8 lambda / functional based. And as well changes
>>>>>>> in the DSL to go with that.
>>>>>>>
>>>>>>> There are some minor code changes needed to make the source compile as
>>>>>>> source 1.8 to go in this Camel 2.18 let alone.
>>>>>>>
>>>>>>>
>>>>>>> b)
>>>>>>> Drop components that do not support and run on Java 1.8
>>>>>>> And potentially remove some deprecated components
>>>>>>>
>>>>>>>
>>>>>>> c)
>>>>>>> Drop karaf 2.x.
>>>>>>> And move to karaf 4.x for all our testing.
>>>>>>>
>>>>>>>
>>>>>>> d)
>>>>>>> Drop Jetty 8.x.
>>>>>>>
>>>>>>> This also requires to upgrade at least two components that currently
>>>>>>> rely on Jetty 8 to use Jetty 9.
>>>>>>>
>>>>>>>
>>>>>>> e)
>>>>>>> Upgrade to latest Jetty 9.
>>>>>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>>>>>
>>>>>>>
>>>>>>> f)
>>>>>>> Drop support for older versions of Spring. We have a number of
>>>>>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>>>>>> spring 4.0. as its also EOL.
>>>>>>>
>>>>>>>
>>>>>>> g)
>>>>>>> Potentially move spring-dm out of camel-spring into a camel-spring-dm
>>>>>>> module. So camel-spring can use latest version of Spring safely. This
>>>>>>> also makes it easier to deprecated spring-dm and remove it eventually.
>>>>>>> The Karaf team is working on a sping -> blueprint layer so you can use
>>>>>>> spring xml files but Karaf will "convert" that under the hood to
>>>>>>> blueprint and run it as blueprint. When that is ready we no longer
>>>>>>> need spring-dm.
>>>>>>>
>>>>>>>
>>>>>>> h)
>>>>>>> Continue adding components docs in the source, eg src/main/doc files.
>>>>>>> So we eventually have as many/all of them. This is an ongoing effort,
>>>>>>> as we need to do this for the EIPs and the other parts of the docs.
>>>>>>>
>>>>>>> However I see this as a great step for a new documentation and
>>>>>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>>>>>> website fresh and modern. And make the documentation easier for end
>>>>>>> users to use and view.
>>>>>>>
>>>>>>>
>>>>>>> i)
>>>>>>> Add camel-hysterix component and integrate camel's circuit breaker
>>>>>>> into turbine/hysterix so you can see metrics from camel in the
>>>>>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>>>>>
>>>>>>>
>>>>>>> j)
>>>>>>> Split camel-cxf into modules so we can separate WS and RS and also
>>>>>>> spring vs blueprint. Today its big ball of dependencies that is a bit
>>>>>>> hard to slice and dice. Specially for MSA style with REST and you dont
>>>>>>> want to add in a bunch of extra not needed JARs.
>>>>>>>
>>>>>>>
>>>>>>> k)
>>>>>>> Continue as usual by adding new components, data formats, fix bugs, and so on.
>>>>>>>
>>>>>>>
>>>>>>> l)
>>>>>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>>>>>> could try to get this "stepping stone" release done sooner, so it can
>>>>>>> be released during/shortly after summer.
>>>>>>>
>>>>>>> There is plenty of "first work" that we must do with the java 8
>>>>>>> upgrade and dropping older techs etc, that we have our hands full for
>>>>>>> a while.
>>>>>>>
>>>>>>> Doing a release with these changes allows our end users to migrate
>>>>>>> along in a easy way, than a big bang - breaking apis - release would
>>>>>>> do. And the latter would be more appropriate to be released as Camel
>>>>>>> 3.0.
>>>>>>>
>>>>>>> Then towards the end of this year, we can see where we are and plan
>>>>>>> for a Camel 3.0 with a new website and documentation that such a
>>>>>>> release deserve. For example if we release Camel 3.0 in start of 2017
>>>>>>> then its also Camel's 10 year birthday year.
>>>>>>>
>>>>>>> And doing such a release with a rewamped website with fresh looking
>>>>>>> documentation and content, is what helps the project a lot.
>>>>>>>
>>>>>>> The current website looks the same as it did when it was created:
>>>>>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>>>>>
>>>>>>> PS: We surely also need a better "what is Camel" story on the front
>>>>>>> page. Its still that very first one with all the tech jumble that was
>>>>>>> initially created.
>>>>>>>
>>>>>>> PPS: I would also love to see a new Camel logo. The current one is a
>>>>>>> bit dull and boring.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>
>


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

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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Claus Ibsen-2
Hi

On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider
<[hidden email]> wrote:
> I recently worked on some projects that also need OSGi settings and found an
> interesting thing.
> It seems the easiest way to get the exports, imports and other OSGi settings
> right is not to use central defaults and instead do all settings per project
> while relying on defaults as much as possible.
>

Christian is the wording correct? I read this a bit like "do not use
central defaults" and then "rely on default as much as possible" are
they not the opposite?

Do you mean do not use central defaults. And if you must then as
little as possible?




> I use these settings in the parent:
> https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L199-L223
>
> So basically what I do is to only activate the bundle plugin in the parent
> and set it to not auto export packages. For bnd-maven-plugin this should not
> be necessary as it is the default.
> I then delegate the OSGi settings to a bnd.bnd file. This is largely equal
> to the pom config but a little less verbose.
>
> An example can be found at:
> https://github.com/apache/aries-rsa/tree/master/rsa
> https://github.com/apache/aries-rsa/blob/master/rsa/bnd.bnd
>
> As you see the pom of each project contains no OSGi informations at all and
> the bnd.bnd files are very small.
> So I would recommend this approach for camel too.
>

Ah so instead of having osgi stuff mixed around in parent central pom
files, and then with some overlays in current pom.xml, you are solely
using a bnd.bnd file per module.

So that would mean we would need to do a bnd.bnd file per Camel module
that is an OSGi bundle?
And how much do you need to configure those bnd.bnd files? Today we
get the import|export generated.


> Christian
>
>
> On 24.03.2016 16:18, Claus Ibsen wrote:
>>
>> On Thu, Mar 24, 2016 at 4:10 PM, Quinn Stevenson
>> <[hidden email]> wrote:
>>>
>>> I’d be happy to take a shot at the conversion.  Is there an appropriate
>>> JIRA created already?  Or should I continue what you started on the
>>> osgi-trouble branch?
>>>
>> I suggest to start a new branch. The osgi-trouble branch includes
>> another upgrade as well that surfaced a bug in the old felix
>> bundle-plugin. If we get the osgi fixed then we can cherry-pick the
>> caffiene upgrade that are in this branch also.
>>
>> The new branch could try to aim at
>>
>> - try to use the bnd plugin
>> - if that fails try to upgrade to newer felix plugin
>> - upgrade to newer osgi (is that version 5.0 ?)
>> - there is some default osgi imports in the parent pom.xml that likely
>> need upgrades (i think its in the parent pom)
>>
>> And a related project is to upgrade the osgi tests in the tests
>> directory to use karaf 4.x by default.
>>
>>
>>
>>
>>>> On Mar 24, 2016, at 8:37 AM, Claus Ibsen <[hidden email]> wrote:
>>>>
>>>> Hi
>>>>
>>>> Thanks for sharing the details about the bnd maven plugin. Sounds
>>>> promising if its more active maintained and is better.
>>>>
>>>> Anyone is surely welcome to give it a go on the Camel master branch.
>>>> The build system is a bit complicated as there is some default stuff
>>>> in parent pom.xml and some ant magic to "massage" maven vs osgi
>>>> versions when using SNAPSHOTs and whatnot. Its all part of some old
>>>> stuff we needed many years ago when OSGi was new and more buggy.
>>>>
>>>> I am not so sure we need all that anymore, it would be lovely to make
>>>> the build system simpler and easier.
>>>>
>>>> Sadly I have not seen any tools that can compare a set of JARs against
>>>> other JARs to see if their MANIFEST.MF is "the same". Its a bit scary
>>>> if the new plugin generates "wrong" imports/exports and the only way
>>>> to be sure it works is to run it all in a real osgi container and try
>>>> all the components for real. Not only just see if the component can be
>>>> installed.
>>>>
>>>> But then this is what the community is for - to help test - especially
>>>> for the people who are using OSGi.
>>>> People who are not, you are missing out all the fun ;) ..... or maybe
>>>> not.
>>>>
>>>> A fallback plan is to keep using the old 2.3.7 plugin and then maybe
>>>> "hand craft" the camel-core pom.xml instead of generating it to
>>>> workaround its issue with Java 1.8 and the caffeine cache. But then we
>>>> are stuck on this old dead horse still.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Mar 24, 2016 at 2:47 PM, Quinn Stevenson
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Antonin/Claus -
>>>>>
>>>>> I’ve used the bnd-maven-plugin, and it dramatically reduced the amount
>>>>> of configuration I had to do for my bundles.  I hit a bug in
>>>>> maven-bundle-plugin (https://issues.apache.org/jira/browse/FELIX-5179) and
>>>>> moving to the bnd-maven-plugin allowed me to what I needed to do.  I even
>>>>> provided a patch for the maven-bundle-plugin, but it has yet to be applied.
>>>>>
>>>>> I haven’t explored the intricacies of the Camel build as far as bundle
>>>>> manifests are concerned, but I think it would be worthwhile to try the
>>>>> bnd-maven-plugin.
>>>>>
>>>>>
>>>>>> On Mar 24, 2016, at 2:28 AM, Antonin Stefanutti
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>> Hi Claus,
>>>>>>
>>>>>> Just in case for info, there is apparently a new BND Maven plugin [1]
>>>>>> that is supposed to alleviate some of the issues encountered with
>>>>>> maven-bundle-plugin.
>>>>>>
>>>>>> I haven’t tried it (nor am knowledgeable in the area) but that may be
>>>>>> good to know at some point for that piece of work.
>>>>>>
>>>>>> [1]:
>>>>>> http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html
>>>>>>
>>>>>> Antonin
>>>>>>
>>>>>>> On 24 Mar 2016, at 07:44, Claus Ibsen <[hidden email]> wrote:
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> m)
>>>>>>> Upgrade OSGi
>>>>>>>
>>>>>>> We are using osgi 4.3.1 version which whatever OSGi version that is.
>>>>>>> But there is a OSGi 5.0 that newer Karaf containers uses.
>>>>>>>
>>>>>>> But the big pain is upgrading maven-bundle-plugin. We are currently
>>>>>>> using an old 2.3.7. But the newer versions have their new sets of
>>>>>>> problems / fixes.
>>>>>>>
>>>>>>> i have struggled with newer versions generating missing details in
>>>>>>> the
>>>>>>> manifest.mf files. For example camel-core did not export all its
>>>>>>> packages etc. A bit scary. But we do have a fair bit of maven
>>>>>>> properties and other osgi "magic" to make the build process build
>>>>>>> OSGi
>>>>>>> modules across all the 250 or so artifacts.
>>>>>>>
>>>>>>> I pushed to a branch called osgi-trouble where you can see some of
>>>>>>> this problems
>>>>>>> https://github.com/apache/camel/commits/osgi-trouble
>>>>>>>
>>>>>>> Using the latest 3.0.1 bundle plugin fails to build camel-core. It
>>>>>>> complains something about the osgi activator.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 23, 2016 at 11:07 AM, Claus Ibsen <[hidden email]>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> So Camel 2.17 was the last release supporting Java 1.7.
>>>>>>>> The next Camel 2.18 is requiring Java 1.8.
>>>>>>>>
>>>>>>>> Here is some thoughts of mine about this release up for discussion.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> a)
>>>>>>>> I see the overall goal of Camel 2.18 as a stepping stone towards
>>>>>>>> Java
>>>>>>>> 1.8 and Camel 3.0.
>>>>>>>>
>>>>>>>> By that I mean the release should be a way of moving our existing
>>>>>>>> users from Java 1.7 and the current Camel APIs and the likes
>>>>>>>> gradually
>>>>>>>> towards Java 1.8 and eventually Camel 3.0.
>>>>>>>>
>>>>>>>> In other words we should not get carried away to change/break APIs
>>>>>>>> and
>>>>>>>> whatnot just because Java 1.8 lambdas and functions.
>>>>>>>>
>>>>>>>> There are too many current users that rely on the current Camel API
>>>>>>>> and we cannot go around change processor / expression / predicate /
>>>>>>>> aggregation strategy and other interfaces to be java 8 functional if
>>>>>>>> that means current code cannot compile. And certainly not adding
>>>>>>>> Optional<X> as return types all over.
>>>>>>>>
>>>>>>>> The following releases (Camel 2.19 or 3.0) can pick up that torch
>>>>>>>> and
>>>>>>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>>>>>>> changes that are Java 8 lambda / functional based. And as well
>>>>>>>> changes
>>>>>>>> in the DSL to go with that.
>>>>>>>>
>>>>>>>> There are some minor code changes needed to make the source compile
>>>>>>>> as
>>>>>>>> source 1.8 to go in this Camel 2.18 let alone.
>>>>>>>>
>>>>>>>>
>>>>>>>> b)
>>>>>>>> Drop components that do not support and run on Java 1.8
>>>>>>>> And potentially remove some deprecated components
>>>>>>>>
>>>>>>>>
>>>>>>>> c)
>>>>>>>> Drop karaf 2.x.
>>>>>>>> And move to karaf 4.x for all our testing.
>>>>>>>>
>>>>>>>>
>>>>>>>> d)
>>>>>>>> Drop Jetty 8.x.
>>>>>>>>
>>>>>>>> This also requires to upgrade at least two components that currently
>>>>>>>> rely on Jetty 8 to use Jetty 9.
>>>>>>>>
>>>>>>>>
>>>>>>>> e)
>>>>>>>> Upgrade to latest Jetty 9.
>>>>>>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>>>>>>
>>>>>>>>
>>>>>>>> f)
>>>>>>>> Drop support for older versions of Spring. We have a number of
>>>>>>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>>>>>>> spring 4.0. as its also EOL.
>>>>>>>>
>>>>>>>>
>>>>>>>> g)
>>>>>>>> Potentially move spring-dm out of camel-spring into a
>>>>>>>> camel-spring-dm
>>>>>>>> module. So camel-spring can use latest version of Spring safely.
>>>>>>>> This
>>>>>>>> also makes it easier to deprecated spring-dm and remove it
>>>>>>>> eventually.
>>>>>>>> The Karaf team is working on a sping -> blueprint layer so you can
>>>>>>>> use
>>>>>>>> spring xml files but Karaf will "convert" that under the hood to
>>>>>>>> blueprint and run it as blueprint. When that is ready we no longer
>>>>>>>> need spring-dm.
>>>>>>>>
>>>>>>>>
>>>>>>>> h)
>>>>>>>> Continue adding components docs in the source, eg src/main/doc
>>>>>>>> files.
>>>>>>>> So we eventually have as many/all of them. This is an ongoing
>>>>>>>> effort,
>>>>>>>> as we need to do this for the EIPs and the other parts of the docs.
>>>>>>>>
>>>>>>>> However I see this as a great step for a new documentation and
>>>>>>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>>>>>>> website fresh and modern. And make the documentation easier for end
>>>>>>>> users to use and view.
>>>>>>>>
>>>>>>>>
>>>>>>>> i)
>>>>>>>> Add camel-hysterix component and integrate camel's circuit breaker
>>>>>>>> into turbine/hysterix so you can see metrics from camel in the
>>>>>>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>>>>>>
>>>>>>>>
>>>>>>>> j)
>>>>>>>> Split camel-cxf into modules so we can separate WS and RS and also
>>>>>>>> spring vs blueprint. Today its big ball of dependencies that is a
>>>>>>>> bit
>>>>>>>> hard to slice and dice. Specially for MSA style with REST and you
>>>>>>>> dont
>>>>>>>> want to add in a bunch of extra not needed JARs.
>>>>>>>>
>>>>>>>>
>>>>>>>> k)
>>>>>>>> Continue as usual by adding new components, data formats, fix bugs,
>>>>>>>> and so on.
>>>>>>>>
>>>>>>>>
>>>>>>>> l)
>>>>>>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>>>>>>> could try to get this "stepping stone" release done sooner, so it
>>>>>>>> can
>>>>>>>> be released during/shortly after summer.
>>>>>>>>
>>>>>>>> There is plenty of "first work" that we must do with the java 8
>>>>>>>> upgrade and dropping older techs etc, that we have our hands full
>>>>>>>> for
>>>>>>>> a while.
>>>>>>>>
>>>>>>>> Doing a release with these changes allows our end users to migrate
>>>>>>>> along in a easy way, than a big bang - breaking apis - release would
>>>>>>>> do. And the latter would be more appropriate to be released as Camel
>>>>>>>> 3.0.
>>>>>>>>
>>>>>>>> Then towards the end of this year, we can see where we are and plan
>>>>>>>> for a Camel 3.0 with a new website and documentation that such a
>>>>>>>> release deserve. For example if we release Camel 3.0 in start of
>>>>>>>> 2017
>>>>>>>> then its also Camel's 10 year birthday year.
>>>>>>>>
>>>>>>>> And doing such a release with a rewamped website with fresh looking
>>>>>>>> documentation and content, is what helps the project a lot.
>>>>>>>>
>>>>>>>> The current website looks the same as it did when it was created:
>>>>>>>>
>>>>>>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>>>>>>
>>>>>>>> PS: We surely also need a better "what is Camel" story on the front
>>>>>>>> page. Its still that very first one with all the tech jumble that
>>>>>>>> was
>>>>>>>> initially created.
>>>>>>>>
>>>>>>>> PPS: I would also love to see a new Camel logo. The current one is a
>>>>>>>> bit dull and boring.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Quinn Stevenson
One clarification on the bnd-maven-plugin configuration - it will inherit configuration from parent bnd.bnd files, so we can have the common configuration we want in the top-level directory, and only override it when needed.

Also - there are some “information only” headers in put in the MANIFEST.MF now (like Import-Service and Export-Service) - do we need those?

As Christian said, the tools do a very good job of calculating imported packages.  Depending on what we want exported, the Export-Package header may be configured globally as well.

> On Apr 1, 2016, at 1:17 AM, Claus Ibsen <[hidden email]> wrote:
>
> Hi
>
> On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider
> <[hidden email] <mailto:[hidden email]>> wrote:
>> I recently worked on some projects that also need OSGi settings and found an
>> interesting thing.
>> It seems the easiest way to get the exports, imports and other OSGi settings
>> right is not to use central defaults and instead do all settings per project
>> while relying on defaults as much as possible.
>>
>
> Christian is the wording correct? I read this a bit like "do not use
> central defaults" and then "rely on default as much as possible" are
> they not the opposite?
>
> Do you mean do not use central defaults. And if you must then as
> little as possible?
>
>
>
>
>> I use these settings in the parent:
>> https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L199-L223
>>
>> So basically what I do is to only activate the bundle plugin in the parent
>> and set it to not auto export packages. For bnd-maven-plugin this should not
>> be necessary as it is the default.
>> I then delegate the OSGi settings to a bnd.bnd file. This is largely equal
>> to the pom config but a little less verbose.
>>
>> An example can be found at:
>> https://github.com/apache/aries-rsa/tree/master/rsa
>> https://github.com/apache/aries-rsa/blob/master/rsa/bnd.bnd
>>
>> As you see the pom of each project contains no OSGi informations at all and
>> the bnd.bnd files are very small.
>> So I would recommend this approach for camel too.
>>
>
> Ah so instead of having osgi stuff mixed around in parent central pom
> files, and then with some overlays in current pom.xml, you are solely
> using a bnd.bnd file per module.
>
> So that would mean we would need to do a bnd.bnd file per Camel module
> that is an OSGi bundle?
> And how much do you need to configure those bnd.bnd files? Today we
> get the import|export generated.
>
>
>> Christian
>>
>>
>> On 24.03.2016 16:18, Claus Ibsen wrote:
>>>
>>> On Thu, Mar 24, 2016 at 4:10 PM, Quinn Stevenson
>>> <[hidden email]> wrote:
>>>>
>>>> I’d be happy to take a shot at the conversion.  Is there an appropriate
>>>> JIRA created already?  Or should I continue what you started on the
>>>> osgi-trouble branch?
>>>>
>>> I suggest to start a new branch. The osgi-trouble branch includes
>>> another upgrade as well that surfaced a bug in the old felix
>>> bundle-plugin. If we get the osgi fixed then we can cherry-pick the
>>> caffiene upgrade that are in this branch also.
>>>
>>> The new branch could try to aim at
>>>
>>> - try to use the bnd plugin
>>> - if that fails try to upgrade to newer felix plugin
>>> - upgrade to newer osgi (is that version 5.0 ?)
>>> - there is some default osgi imports in the parent pom.xml that likely
>>> need upgrades (i think its in the parent pom)
>>>
>>> And a related project is to upgrade the osgi tests in the tests
>>> directory to use karaf 4.x by default.
>>>
>>>
>>>
>>>
>>>>> On Mar 24, 2016, at 8:37 AM, Claus Ibsen <[hidden email]> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> Thanks for sharing the details about the bnd maven plugin. Sounds
>>>>> promising if its more active maintained and is better.
>>>>>
>>>>> Anyone is surely welcome to give it a go on the Camel master branch.
>>>>> The build system is a bit complicated as there is some default stuff
>>>>> in parent pom.xml and some ant magic to "massage" maven vs osgi
>>>>> versions when using SNAPSHOTs and whatnot. Its all part of some old
>>>>> stuff we needed many years ago when OSGi was new and more buggy.
>>>>>
>>>>> I am not so sure we need all that anymore, it would be lovely to make
>>>>> the build system simpler and easier.
>>>>>
>>>>> Sadly I have not seen any tools that can compare a set of JARs against
>>>>> other JARs to see if their MANIFEST.MF is "the same". Its a bit scary
>>>>> if the new plugin generates "wrong" imports/exports and the only way
>>>>> to be sure it works is to run it all in a real osgi container and try
>>>>> all the components for real. Not only just see if the component can be
>>>>> installed.
>>>>>
>>>>> But then this is what the community is for - to help test - especially
>>>>> for the people who are using OSGi.
>>>>> People who are not, you are missing out all the fun ;) ..... or maybe
>>>>> not.
>>>>>
>>>>> A fallback plan is to keep using the old 2.3.7 plugin and then maybe
>>>>> "hand craft" the camel-core pom.xml instead of generating it to
>>>>> workaround its issue with Java 1.8 and the caffeine cache. But then we
>>>>> are stuck on this old dead horse still.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 24, 2016 at 2:47 PM, Quinn Stevenson
>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>> Antonin/Claus -
>>>>>>
>>>>>> I’ve used the bnd-maven-plugin, and it dramatically reduced the amount
>>>>>> of configuration I had to do for my bundles.  I hit a bug in
>>>>>> maven-bundle-plugin (https://issues.apache.org/jira/browse/FELIX-5179) and
>>>>>> moving to the bnd-maven-plugin allowed me to what I needed to do.  I even
>>>>>> provided a patch for the maven-bundle-plugin, but it has yet to be applied.
>>>>>>
>>>>>> I haven’t explored the intricacies of the Camel build as far as bundle
>>>>>> manifests are concerned, but I think it would be worthwhile to try the
>>>>>> bnd-maven-plugin.
>>>>>>
>>>>>>
>>>>>>> On Mar 24, 2016, at 2:28 AM, Antonin Stefanutti
>>>>>>> <[hidden email]> wrote:
>>>>>>>
>>>>>>> Hi Claus,
>>>>>>>
>>>>>>> Just in case for info, there is apparently a new BND Maven plugin [1]
>>>>>>> that is supposed to alleviate some of the issues encountered with
>>>>>>> maven-bundle-plugin.
>>>>>>>
>>>>>>> I haven’t tried it (nor am knowledgeable in the area) but that may be
>>>>>>> good to know at some point for that piece of work.
>>>>>>>
>>>>>>> [1]:
>>>>>>> http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html
>>>>>>>
>>>>>>> Antonin
>>>>>>>
>>>>>>>> On 24 Mar 2016, at 07:44, Claus Ibsen <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> m)
>>>>>>>> Upgrade OSGi
>>>>>>>>
>>>>>>>> We are using osgi 4.3.1 version which whatever OSGi version that is.
>>>>>>>> But there is a OSGi 5.0 that newer Karaf containers uses.
>>>>>>>>
>>>>>>>> But the big pain is upgrading maven-bundle-plugin. We are currently
>>>>>>>> using an old 2.3.7. But the newer versions have their new sets of
>>>>>>>> problems / fixes.
>>>>>>>>
>>>>>>>> i have struggled with newer versions generating missing details in
>>>>>>>> the
>>>>>>>> manifest.mf files. For example camel-core did not export all its
>>>>>>>> packages etc. A bit scary. But we do have a fair bit of maven
>>>>>>>> properties and other osgi "magic" to make the build process build
>>>>>>>> OSGi
>>>>>>>> modules across all the 250 or so artifacts.
>>>>>>>>
>>>>>>>> I pushed to a branch called osgi-trouble where you can see some of
>>>>>>>> this problems
>>>>>>>> https://github.com/apache/camel/commits/osgi-trouble
>>>>>>>>
>>>>>>>> Using the latest 3.0.1 bundle plugin fails to build camel-core. It
>>>>>>>> complains something about the osgi activator.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 23, 2016 at 11:07 AM, Claus Ibsen <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> So Camel 2.17 was the last release supporting Java 1.7.
>>>>>>>>> The next Camel 2.18 is requiring Java 1.8.
>>>>>>>>>
>>>>>>>>> Here is some thoughts of mine about this release up for discussion.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> a)
>>>>>>>>> I see the overall goal of Camel 2.18 as a stepping stone towards
>>>>>>>>> Java
>>>>>>>>> 1.8 and Camel 3.0.
>>>>>>>>>
>>>>>>>>> By that I mean the release should be a way of moving our existing
>>>>>>>>> users from Java 1.7 and the current Camel APIs and the likes
>>>>>>>>> gradually
>>>>>>>>> towards Java 1.8 and eventually Camel 3.0.
>>>>>>>>>
>>>>>>>>> In other words we should not get carried away to change/break APIs
>>>>>>>>> and
>>>>>>>>> whatnot just because Java 1.8 lambdas and functions.
>>>>>>>>>
>>>>>>>>> There are too many current users that rely on the current Camel API
>>>>>>>>> and we cannot go around change processor / expression / predicate /
>>>>>>>>> aggregation strategy and other interfaces to be java 8 functional if
>>>>>>>>> that means current code cannot compile. And certainly not adding
>>>>>>>>> Optional<X> as return types all over.
>>>>>>>>>
>>>>>>>>> The following releases (Camel 2.19 or 3.0) can pick up that torch
>>>>>>>>> and
>>>>>>>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>>>>>>>> changes that are Java 8 lambda / functional based. And as well
>>>>>>>>> changes
>>>>>>>>> in the DSL to go with that.
>>>>>>>>>
>>>>>>>>> There are some minor code changes needed to make the source compile
>>>>>>>>> as
>>>>>>>>> source 1.8 to go in this Camel 2.18 let alone.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> b)
>>>>>>>>> Drop components that do not support and run on Java 1.8
>>>>>>>>> And potentially remove some deprecated components
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> c)
>>>>>>>>> Drop karaf 2.x.
>>>>>>>>> And move to karaf 4.x for all our testing.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> d)
>>>>>>>>> Drop Jetty 8.x.
>>>>>>>>>
>>>>>>>>> This also requires to upgrade at least two components that currently
>>>>>>>>> rely on Jetty 8 to use Jetty 9.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> e)
>>>>>>>>> Upgrade to latest Jetty 9.
>>>>>>>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> f)
>>>>>>>>> Drop support for older versions of Spring. We have a number of
>>>>>>>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>>>>>>>> spring 4.0. as its also EOL.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> g)
>>>>>>>>> Potentially move spring-dm out of camel-spring into a
>>>>>>>>> camel-spring-dm
>>>>>>>>> module. So camel-spring can use latest version of Spring safely.
>>>>>>>>> This
>>>>>>>>> also makes it easier to deprecated spring-dm and remove it
>>>>>>>>> eventually.
>>>>>>>>> The Karaf team is working on a sping -> blueprint layer so you can
>>>>>>>>> use
>>>>>>>>> spring xml files but Karaf will "convert" that under the hood to
>>>>>>>>> blueprint and run it as blueprint. When that is ready we no longer
>>>>>>>>> need spring-dm.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> h)
>>>>>>>>> Continue adding components docs in the source, eg src/main/doc
>>>>>>>>> files.
>>>>>>>>> So we eventually have as many/all of them. This is an ongoing
>>>>>>>>> effort,
>>>>>>>>> as we need to do this for the EIPs and the other parts of the docs.
>>>>>>>>>
>>>>>>>>> However I see this as a great step for a new documentation and
>>>>>>>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>>>>>>>> website fresh and modern. And make the documentation easier for end
>>>>>>>>> users to use and view.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> i)
>>>>>>>>> Add camel-hysterix component and integrate camel's circuit breaker
>>>>>>>>> into turbine/hysterix so you can see metrics from camel in the
>>>>>>>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> j)
>>>>>>>>> Split camel-cxf into modules so we can separate WS and RS and also
>>>>>>>>> spring vs blueprint. Today its big ball of dependencies that is a
>>>>>>>>> bit
>>>>>>>>> hard to slice and dice. Specially for MSA style with REST and you
>>>>>>>>> dont
>>>>>>>>> want to add in a bunch of extra not needed JARs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> k)
>>>>>>>>> Continue as usual by adding new components, data formats, fix bugs,
>>>>>>>>> and so on.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> l)
>>>>>>>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>>>>>>>> could try to get this "stepping stone" release done sooner, so it
>>>>>>>>> can
>>>>>>>>> be released during/shortly after summer.
>>>>>>>>>
>>>>>>>>> There is plenty of "first work" that we must do with the java 8
>>>>>>>>> upgrade and dropping older techs etc, that we have our hands full
>>>>>>>>> for
>>>>>>>>> a while.
>>>>>>>>>
>>>>>>>>> Doing a release with these changes allows our end users to migrate
>>>>>>>>> along in a easy way, than a big bang - breaking apis - release would
>>>>>>>>> do. And the latter would be more appropriate to be released as Camel
>>>>>>>>> 3.0.
>>>>>>>>>
>>>>>>>>> Then towards the end of this year, we can see where we are and plan
>>>>>>>>> for a Camel 3.0 with a new website and documentation that such a
>>>>>>>>> release deserve. For example if we release Camel 3.0 in start of
>>>>>>>>> 2017
>>>>>>>>> then its also Camel's 10 year birthday year.
>>>>>>>>>
>>>>>>>>> And doing such a release with a rewamped website with fresh looking
>>>>>>>>> documentation and content, is what helps the project a lot.
>>>>>>>>>
>>>>>>>>> The current website looks the same as it did when it was created:
>>>>>>>>>
>>>>>>>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>>>>>>>
>>>>>>>>> PS: We surely also need a better "what is Camel" story on the front
>>>>>>>>> page. Its still that very first one with all the tech jumble that
>>>>>>>>> was
>>>>>>>>> initially created.
>>>>>>>>>
>>>>>>>>> PPS: I would also love to see a new Camel logo. The current one is a
>>>>>>>>> bit dull and boring.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>
>>>
>>>
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

David Jencks-2
I’d suggest replacing the obsolete Import-Service and Export-Service with actually useful Require-Capability and Provide-Capability headers.

david jencks

> On Apr 1, 2016, at 7:01 AM, Quinn Stevenson <[hidden email]> wrote:
>
> One clarification on the bnd-maven-plugin configuration - it will inherit configuration from parent bnd.bnd files, so we can have the common configuration we want in the top-level directory, and only override it when needed.
>
> Also - there are some “information only” headers in put in the MANIFEST.MF now (like Import-Service and Export-Service) - do we need those?
>
> As Christian said, the tools do a very good job of calculating imported packages.  Depending on what we want exported, the Export-Package header may be configured globally as well.
>
>> On Apr 1, 2016, at 1:17 AM, Claus Ibsen <[hidden email]> wrote:
>>
>> Hi
>>
>> On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>> I recently worked on some projects that also need OSGi settings and found an
>>> interesting thing.
>>> It seems the easiest way to get the exports, imports and other OSGi settings
>>> right is not to use central defaults and instead do all settings per project
>>> while relying on defaults as much as possible.
>>>
>>
>> Christian is the wording correct? I read this a bit like "do not use
>> central defaults" and then "rely on default as much as possible" are
>> they not the opposite?
>>
>> Do you mean do not use central defaults. And if you must then as
>> little as possible?
>>
>>
>>
>>
>>> I use these settings in the parent:
>>> https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L199-L223
>>>
>>> So basically what I do is to only activate the bundle plugin in the parent
>>> and set it to not auto export packages. For bnd-maven-plugin this should not
>>> be necessary as it is the default.
>>> I then delegate the OSGi settings to a bnd.bnd file. This is largely equal
>>> to the pom config but a little less verbose.
>>>
>>> An example can be found at:
>>> https://github.com/apache/aries-rsa/tree/master/rsa
>>> https://github.com/apache/aries-rsa/blob/master/rsa/bnd.bnd
>>>
>>> As you see the pom of each project contains no OSGi informations at all and
>>> the bnd.bnd files are very small.
>>> So I would recommend this approach for camel too.
>>>
>>
>> Ah so instead of having osgi stuff mixed around in parent central pom
>> files, and then with some overlays in current pom.xml, you are solely
>> using a bnd.bnd file per module.
>>
>> So that would mean we would need to do a bnd.bnd file per Camel module
>> that is an OSGi bundle?
>> And how much do you need to configure those bnd.bnd files? Today we
>> get the import|export generated.
>>
>>
>>> Christian
>>>
>>>
>>> On 24.03.2016 16:18, Claus Ibsen wrote:
>>>>
>>>> On Thu, Mar 24, 2016 at 4:10 PM, Quinn Stevenson
>>>> <[hidden email]> wrote:
>>>>>
>>>>> I’d be happy to take a shot at the conversion.  Is there an appropriate
>>>>> JIRA created already?  Or should I continue what you started on the
>>>>> osgi-trouble branch?
>>>>>
>>>> I suggest to start a new branch. The osgi-trouble branch includes
>>>> another upgrade as well that surfaced a bug in the old felix
>>>> bundle-plugin. If we get the osgi fixed then we can cherry-pick the
>>>> caffiene upgrade that are in this branch also.
>>>>
>>>> The new branch could try to aim at
>>>>
>>>> - try to use the bnd plugin
>>>> - if that fails try to upgrade to newer felix plugin
>>>> - upgrade to newer osgi (is that version 5.0 ?)
>>>> - there is some default osgi imports in the parent pom.xml that likely
>>>> need upgrades (i think its in the parent pom)
>>>>
>>>> And a related project is to upgrade the osgi tests in the tests
>>>> directory to use karaf 4.x by default.
>>>>
>>>>
>>>>
>>>>
>>>>>> On Mar 24, 2016, at 8:37 AM, Claus Ibsen <[hidden email]> wrote:
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Thanks for sharing the details about the bnd maven plugin. Sounds
>>>>>> promising if its more active maintained and is better.
>>>>>>
>>>>>> Anyone is surely welcome to give it a go on the Camel master branch.
>>>>>> The build system is a bit complicated as there is some default stuff
>>>>>> in parent pom.xml and some ant magic to "massage" maven vs osgi
>>>>>> versions when using SNAPSHOTs and whatnot. Its all part of some old
>>>>>> stuff we needed many years ago when OSGi was new and more buggy.
>>>>>>
>>>>>> I am not so sure we need all that anymore, it would be lovely to make
>>>>>> the build system simpler and easier.
>>>>>>
>>>>>> Sadly I have not seen any tools that can compare a set of JARs against
>>>>>> other JARs to see if their MANIFEST.MF is "the same". Its a bit scary
>>>>>> if the new plugin generates "wrong" imports/exports and the only way
>>>>>> to be sure it works is to run it all in a real osgi container and try
>>>>>> all the components for real. Not only just see if the component can be
>>>>>> installed.
>>>>>>
>>>>>> But then this is what the community is for - to help test - especially
>>>>>> for the people who are using OSGi.
>>>>>> People who are not, you are missing out all the fun ;) ..... or maybe
>>>>>> not.
>>>>>>
>>>>>> A fallback plan is to keep using the old 2.3.7 plugin and then maybe
>>>>>> "hand craft" the camel-core pom.xml instead of generating it to
>>>>>> workaround its issue with Java 1.8 and the caffeine cache. But then we
>>>>>> are stuck on this old dead horse still.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 24, 2016 at 2:47 PM, Quinn Stevenson
>>>>>> <[hidden email]> wrote:
>>>>>>>
>>>>>>> Antonin/Claus -
>>>>>>>
>>>>>>> I’ve used the bnd-maven-plugin, and it dramatically reduced the amount
>>>>>>> of configuration I had to do for my bundles.  I hit a bug in
>>>>>>> maven-bundle-plugin (https://issues.apache.org/jira/browse/FELIX-5179) and
>>>>>>> moving to the bnd-maven-plugin allowed me to what I needed to do.  I even
>>>>>>> provided a patch for the maven-bundle-plugin, but it has yet to be applied.
>>>>>>>
>>>>>>> I haven’t explored the intricacies of the Camel build as far as bundle
>>>>>>> manifests are concerned, but I think it would be worthwhile to try the
>>>>>>> bnd-maven-plugin.
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 24, 2016, at 2:28 AM, Antonin Stefanutti
>>>>>>>> <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Hi Claus,
>>>>>>>>
>>>>>>>> Just in case for info, there is apparently a new BND Maven plugin [1]
>>>>>>>> that is supposed to alleviate some of the issues encountered with
>>>>>>>> maven-bundle-plugin.
>>>>>>>>
>>>>>>>> I haven’t tried it (nor am knowledgeable in the area) but that may be
>>>>>>>> good to know at some point for that piece of work.
>>>>>>>>
>>>>>>>> [1]:
>>>>>>>> http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html
>>>>>>>>
>>>>>>>> Antonin
>>>>>>>>
>>>>>>>>> On 24 Mar 2016, at 07:44, Claus Ibsen <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> m)
>>>>>>>>> Upgrade OSGi
>>>>>>>>>
>>>>>>>>> We are using osgi 4.3.1 version which whatever OSGi version that is.
>>>>>>>>> But there is a OSGi 5.0 that newer Karaf containers uses.
>>>>>>>>>
>>>>>>>>> But the big pain is upgrading maven-bundle-plugin. We are currently
>>>>>>>>> using an old 2.3.7. But the newer versions have their new sets of
>>>>>>>>> problems / fixes.
>>>>>>>>>
>>>>>>>>> i have struggled with newer versions generating missing details in
>>>>>>>>> the
>>>>>>>>> manifest.mf files. For example camel-core did not export all its
>>>>>>>>> packages etc. A bit scary. But we do have a fair bit of maven
>>>>>>>>> properties and other osgi "magic" to make the build process build
>>>>>>>>> OSGi
>>>>>>>>> modules across all the 250 or so artifacts.
>>>>>>>>>
>>>>>>>>> I pushed to a branch called osgi-trouble where you can see some of
>>>>>>>>> this problems
>>>>>>>>> https://github.com/apache/camel/commits/osgi-trouble
>>>>>>>>>
>>>>>>>>> Using the latest 3.0.1 bundle plugin fails to build camel-core. It
>>>>>>>>> complains something about the osgi activator.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 23, 2016 at 11:07 AM, Claus Ibsen <[hidden email]>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> So Camel 2.17 was the last release supporting Java 1.7.
>>>>>>>>>> The next Camel 2.18 is requiring Java 1.8.
>>>>>>>>>>
>>>>>>>>>> Here is some thoughts of mine about this release up for discussion.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> a)
>>>>>>>>>> I see the overall goal of Camel 2.18 as a stepping stone towards
>>>>>>>>>> Java
>>>>>>>>>> 1.8 and Camel 3.0.
>>>>>>>>>>
>>>>>>>>>> By that I mean the release should be a way of moving our existing
>>>>>>>>>> users from Java 1.7 and the current Camel APIs and the likes
>>>>>>>>>> gradually
>>>>>>>>>> towards Java 1.8 and eventually Camel 3.0.
>>>>>>>>>>
>>>>>>>>>> In other words we should not get carried away to change/break APIs
>>>>>>>>>> and
>>>>>>>>>> whatnot just because Java 1.8 lambdas and functions.
>>>>>>>>>>
>>>>>>>>>> There are too many current users that rely on the current Camel API
>>>>>>>>>> and we cannot go around change processor / expression / predicate /
>>>>>>>>>> aggregation strategy and other interfaces to be java 8 functional if
>>>>>>>>>> that means current code cannot compile. And certainly not adding
>>>>>>>>>> Optional<X> as return types all over.
>>>>>>>>>>
>>>>>>>>>> The following releases (Camel 2.19 or 3.0) can pick up that torch
>>>>>>>>>> and
>>>>>>>>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>>>>>>>>> changes that are Java 8 lambda / functional based. And as well
>>>>>>>>>> changes
>>>>>>>>>> in the DSL to go with that.
>>>>>>>>>>
>>>>>>>>>> There are some minor code changes needed to make the source compile
>>>>>>>>>> as
>>>>>>>>>> source 1.8 to go in this Camel 2.18 let alone.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> b)
>>>>>>>>>> Drop components that do not support and run on Java 1.8
>>>>>>>>>> And potentially remove some deprecated components
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> c)
>>>>>>>>>> Drop karaf 2.x.
>>>>>>>>>> And move to karaf 4.x for all our testing.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> d)
>>>>>>>>>> Drop Jetty 8.x.
>>>>>>>>>>
>>>>>>>>>> This also requires to upgrade at least two components that currently
>>>>>>>>>> rely on Jetty 8 to use Jetty 9.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> e)
>>>>>>>>>> Upgrade to latest Jetty 9.
>>>>>>>>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> f)
>>>>>>>>>> Drop support for older versions of Spring. We have a number of
>>>>>>>>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>>>>>>>>> spring 4.0. as its also EOL.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> g)
>>>>>>>>>> Potentially move spring-dm out of camel-spring into a
>>>>>>>>>> camel-spring-dm
>>>>>>>>>> module. So camel-spring can use latest version of Spring safely.
>>>>>>>>>> This
>>>>>>>>>> also makes it easier to deprecated spring-dm and remove it
>>>>>>>>>> eventually.
>>>>>>>>>> The Karaf team is working on a sping -> blueprint layer so you can
>>>>>>>>>> use
>>>>>>>>>> spring xml files but Karaf will "convert" that under the hood to
>>>>>>>>>> blueprint and run it as blueprint. When that is ready we no longer
>>>>>>>>>> need spring-dm.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> h)
>>>>>>>>>> Continue adding components docs in the source, eg src/main/doc
>>>>>>>>>> files.
>>>>>>>>>> So we eventually have as many/all of them. This is an ongoing
>>>>>>>>>> effort,
>>>>>>>>>> as we need to do this for the EIPs and the other parts of the docs.
>>>>>>>>>>
>>>>>>>>>> However I see this as a great step for a new documentation and
>>>>>>>>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>>>>>>>>> website fresh and modern. And make the documentation easier for end
>>>>>>>>>> users to use and view.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> i)
>>>>>>>>>> Add camel-hysterix component and integrate camel's circuit breaker
>>>>>>>>>> into turbine/hysterix so you can see metrics from camel in the
>>>>>>>>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> j)
>>>>>>>>>> Split camel-cxf into modules so we can separate WS and RS and also
>>>>>>>>>> spring vs blueprint. Today its big ball of dependencies that is a
>>>>>>>>>> bit
>>>>>>>>>> hard to slice and dice. Specially for MSA style with REST and you
>>>>>>>>>> dont
>>>>>>>>>> want to add in a bunch of extra not needed JARs.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> k)
>>>>>>>>>> Continue as usual by adding new components, data formats, fix bugs,
>>>>>>>>>> and so on.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> l)
>>>>>>>>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>>>>>>>>> could try to get this "stepping stone" release done sooner, so it
>>>>>>>>>> can
>>>>>>>>>> be released during/shortly after summer.
>>>>>>>>>>
>>>>>>>>>> There is plenty of "first work" that we must do with the java 8
>>>>>>>>>> upgrade and dropping older techs etc, that we have our hands full
>>>>>>>>>> for
>>>>>>>>>> a while.
>>>>>>>>>>
>>>>>>>>>> Doing a release with these changes allows our end users to migrate
>>>>>>>>>> along in a easy way, than a big bang - breaking apis - release would
>>>>>>>>>> do. And the latter would be more appropriate to be released as Camel
>>>>>>>>>> 3.0.
>>>>>>>>>>
>>>>>>>>>> Then towards the end of this year, we can see where we are and plan
>>>>>>>>>> for a Camel 3.0 with a new website and documentation that such a
>>>>>>>>>> release deserve. For example if we release Camel 3.0 in start of
>>>>>>>>>> 2017
>>>>>>>>>> then its also Camel's 10 year birthday year.
>>>>>>>>>>
>>>>>>>>>> And doing such a release with a rewamped website with fresh looking
>>>>>>>>>> documentation and content, is what helps the project a lot.
>>>>>>>>>>
>>>>>>>>>> The current website looks the same as it did when it was created:
>>>>>>>>>>
>>>>>>>>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>>>>>>>>
>>>>>>>>>> PS: We surely also need a better "what is Camel" story on the front
>>>>>>>>>> page. Its still that very first one with all the tech jumble that
>>>>>>>>>> was
>>>>>>>>>> initially created.
>>>>>>>>>>
>>>>>>>>>> PPS: I would also love to see a new Camel logo. The current one is a
>>>>>>>>>> bit dull and boring.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Andreas Gebhardt
In reply to this post by Raul Kripalani-3
Hi,

>> 7.  JSON validator. XML XSD validation is nice and straight forward, but it
>> will be great if we have something similar for JSON as well. like
>> to:json-validator:classpath/response.json
>>
>
> Yep, we should create a component for JSON Schema validations.

I would like to contribute to this (new) component. We use JSON Schema
[1] successfully at work to describe requests and responses for a
RESTfull API in combination with RAML [2].

I would create an task (improvement) on Camel's JIRA and start with an
prototype. Is this okay?

Best Andreas

[1] http://json-schema.org/
[2] http://raml.org/
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Claus Ibsen-2
On Fri, Apr 1, 2016 at 8:56 PM, Andreas Gebhardt
<[hidden email]> wrote:

> Hi,
>
>>> 7.  JSON validator. XML XSD validation is nice and straight forward, but
>>> it
>>> will be great if we have something similar for JSON as well. like
>>> to:json-validator:classpath/response.json
>>>
>>
>> Yep, we should create a component for JSON Schema validations.
>
>
> I would like to contribute to this (new) component. We use JSON Schema [1]
> successfully at work to describe requests and responses for a RESTfull API
> in combination with RAML [2].
>
> I would create an task (improvement) on Camel's JIRA and start with an
> prototype. Is this okay?
>
> Best Andreas
>
> [1] http://json-schema.org/
> [2] http://raml.org/

Yeah sure we love contributions.

Just wonder if swagger can be used instead of raml? swagger is much
more popular.

Swagger is now run under an independt organization
https://openapis.org/specification



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Andreas Gebhardt
> Yeah sure we love contributions.

Awesome - I create a 'Wish' issue on JIRA (CAMEL-9799) to be transparency.

There are two implementations mentioned on JSON Schema [1],
'json-schema-validator' [2] which is created by (one of) the authors of
JSON Schema and 'json-schema' [3].
   Both seems to be compatible with the Apache 2 license. Are there any
thoughts to use either [2] or [3] or should there be a extra layer to
choose by ourself?

> Just wonder if swagger can be used instead of raml? swagger is much
> more popular.
>
> Swagger is now run under an independt organization
> https://openapis.org/specification

You are absolutely right.

We started with Swagger and run into trouble with the annotation based
documentation. The API exposes and consumes resources as JSON. There is
a check/validation process of incoming JSON resources against the
appropriate JSON Schema so we we can rely on mandatory fields without
testing each time. With RAML we can use these schemas without any
adoption. Also the 'Consumer Driven Contracts' [4] pattern goes smoothly
hand-in-hand with support by other 3rd party tools.

[1] http://json-schema.org/implementations.html
[2] https://github.com/fge/json-schema-validator
[3] https://github.com/everit-org/json-schema
[4] http://www.martinfowler.com/articles/consumerDrivenContracts.html
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Christian Schneider
In reply to this post by Claus Ibsen-2
On 01.04.2016 09:17, Claus Ibsen wrote:

> Hi
>
> On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider
> <[hidden email]> wrote:
>> I recently worked on some projects that also need OSGi settings and found an
>> interesting thing.
>> It seems the easiest way to get the exports, imports and other OSGi settings
>> right is not to use central defaults and instead do all settings per project
>> while relying on defaults as much as possible.
>>
> Christian is the wording correct? I read this a bit like "do not use
> central defaults" and then "rely on default as much as possible" are
> they not the opposite?
>
> Do you mean do not use central defaults. And if you must then as
> little as possible?
Sorry .. that was a bit confusing.
What I mean is. I do not set defaults in the parent pom and instead rely
on the defaults of bnd. From this base I apply the necessary settings in
each bnd.bnd file
but in the most minimal way that works.

Christian

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

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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Christian Schneider
In reply to this post by Quinn Stevenson
On 01.04.2016 16:01, Quinn Stevenson wrote:
> One clarification on the bnd-maven-plugin configuration - it will inherit configuration from parent bnd.bnd files, so we can have the common configuration we want in the top-level directory, and only override it when needed.
>
> Also - there are some “information only” headers in put in the MANIFEST.MF now (like Import-Service and Export-Service) - do we need those?
The Import-Service and Export-Service headers are not only for
information. They are actually used at resolve time in karaf. Even more
karaf 4 by default applies a strict validation
that for all services that are imported there is also an export. This is
not defined in the OSGi specs and can also be switched off in karaf. It
only applies though if we use the new
1.3.0 feature namespace.

As David wrote it makes sense to use the Capability headers instead of
the service ones. As creating those headers by hand is quite a lot of
effort I think we need to automate this process.
I created an issue for this a long time ago but never actually got it
implemented. See https://issues.apache.org/jira/browse/CAMEL-8046
>
> As Christian said, the tools do a very good job of calculating imported packages.  Depending on what we want exported, the Export-Package header may be configured globally as well.
For import I agree it should be done as automated as possible. Normally
it should not be necessary to set global defaults for it.
For exports it depends how clean the design is. In an ideal OSGi design
you would normally export. bnd can help with this by a new setting that
only exports packages that also define a package version.

In Camel though users access a lot of the implementations too. So maybe
the simplest thing is to export all packages by default.

Christian

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

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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Matt Pavlovich
In reply to this post by jkorab
Jakub-

Sign me up to help with this.

-Matt

On 3/23/16 9:22 AM, jkorab wrote:

> Claus Ibsen-2 wrote
>> PS: We surely also need a better "what is Camel" story on the front
>> page. Its still that very first one with all the tech jumble that was
>> initially created.
> I would be happy to write something up around this. I have some experience
> in explaining Camel to people :)
>
> Jakub
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Thoughts-on-Apache-Camel-2-18-and-towards-3-0-tp5779549p5779565.html
> Sent from the Camel Development mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Matt Pavlovich
In reply to this post by Claus Ibsen-2
On 3/24/16 3:55 PM, Claus Ibsen wrote:

> On Thu, Mar 24, 2016 at 6:24 PM, Krzysztof Sobkowiak
> <[hidden email]> wrote:
>> Hi
>>
>> I'm not sure how the Camel Core actually looks like (especially the quality and the ability to refactor or make more
>> complicated changes) but I had occasion to talk with some people using Camel and trying to fix some issues (and
>> even saw some discussion in net about the state of Core) who think, the Core became very complicated over the
>> years and it would be very difficult to make big changes in it. I think, it's normal that the software which is developed
>> a long time can have  code which is no more used or should be refactored.
>>
>> I think, the way to Camel 3 should also include the renovation of the Core (if really necessary) or even rewriting and
>> making it more asynchronous, e.g. using rx.java (the later can be eventually part of Camel 4 roadmap if too dangerous
>> for Camel 3).
>>
> No this should not be the goal of Camel 3 IMHO. This is too disruptive
> and would take too much effort and time away from other tasks. The
> most important is to have a modern website, documentation and getting
> started guides, examples and so on. So people can get onboard Camel.
+1
> The renovation of the core is to cleanup all the deprecated stuff and
> we will take a 2nd look after the 2.17 release to identify more stuff
> to mark for deprecation in 2.18 and removal for 3.0.
+1
> Yes for Camel 4 a new reactive/modern core could be on the agenda. And
> then the time gap between Camel 3 and 4 do not have to be 6 years. For
> example Spring is not reactive yet, but they are going there in Spring
> 5.x [1]. So when reactive becomes more main stream (with help from
> Spring) and useable for the average developers then its likely also
> interest for Camel users. Remember Camel users are no the "netflix
> developers". Its use by every day developers. And we have a huge
> community which we should not throw under the bus with risky moves.

Agreed. Our users are Enterprise developers that deploying software for
5-30 years. Having Camel a Camel 3.x with these goals provides a ton of
value to a user base that is large and mostly silent in these conversations.

> People who want to look at reactive frameworks today can take a look
> at vert.x, akka (problem a bit bad due Scala, but I think the company
> behind them are moving to Java). For vert.x then their next release
> will have a vertx-camel component out of the box.
>
> There has been a camel-rx component for several years now, but nobody
> has shown interest in it. Nor is people screaming in this community
> about reactive libraries. In fact people rely on Camel being "not in
> the forefront"
>
>
> [1] - https://spring.io/blog/2015/12/03/spring-framework-5-0-roadmap-update
>
>
>> My 2 cents, but I think, we have here many people who are Camel experts and can say more, whether it makes sense.
>>
>> Kindly regards
>> Krzysztof
>>
>> On 23.03.2016 11:07, Claus Ibsen wrote:
>>> Hi
>>>
>>> So Camel 2.17 was the last release supporting Java 1.7.
>>> The next Camel 2.18 is requiring Java 1.8.
>>>
>>> Here is some thoughts of mine about this release up for discussion.
>>>
>>>
>>>
>>> a)
>>> I see the overall goal of Camel 2.18 as a stepping stone towards Java
>>> 1.8 and Camel 3.0.
>>>
>>> By that I mean the release should be a way of moving our existing
>>> users from Java 1.7 and the current Camel APIs and the likes gradually
>>> towards Java 1.8 and eventually Camel 3.0.
>>>
>>> In other words we should not get carried away to change/break APIs and
>>> whatnot just because Java 1.8 lambdas and functions.
>>>
>>> There are too many current users that rely on the current Camel API
>>> and we cannot go around change processor / expression / predicate /
>>> aggregation strategy and other interfaces to be java 8 functional if
>>> that means current code cannot compile. And certainly not adding
>>> Optional<X> as return types all over.
>>>
>>> The following releases (Camel 2.19 or 3.0) can pick up that torch and
>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>> changes that are Java 8 lambda / functional based. And as well changes
>>> in the DSL to go with that.
>>>
>>> There are some minor code changes needed to make the source compile as
>>> source 1.8 to go in this Camel 2.18 let alone.
>>>
>>>
>>> b)
>>> Drop components that do not support and run on Java 1.8
>>> And potentially remove some deprecated components
>>>
>>>
>>> c)
>>> Drop karaf 2.x.
>>> And move to karaf 4.x for all our testing.
>>>
>>>
>>> d)
>>> Drop Jetty 8.x.
>>>
>>> This also requires to upgrade at least two components that currently
>>> rely on Jetty 8 to use Jetty 9.
>>>
>>>
>>> e)
>>> Upgrade to latest Jetty 9.
>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>
>>>
>>> f)
>>> Drop support for older versions of Spring. We have a number of
>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>> spring 4.0. as its also EOL.
>>>
>>>
>>> g)
>>> Potentially move spring-dm out of camel-spring into a camel-spring-dm
>>> module. So camel-spring can use latest version of Spring safely. This
>>> also makes it easier to deprecated spring-dm and remove it eventually.
>>> The Karaf team is working on a sping -> blueprint layer so you can use
>>> spring xml files but Karaf will "convert" that under the hood to
>>> blueprint and run it as blueprint. When that is ready we no longer
>>> need spring-dm.
>>>
>>>
>>> h)
>>> Continue adding components docs in the source, eg src/main/doc files.
>>> So we eventually have as many/all of them. This is an ongoing effort,
>>> as we need to do this for the EIPs and the other parts of the docs.
>>>
>>> However I see this as a great step for a new documentation and
>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>> website fresh and modern. And make the documentation easier for end
>>> users to use and view.
>>>
>>>
>>> i)
>>> Add camel-hysterix component and integrate camel's circuit breaker
>>> into turbine/hysterix so you can see metrics from camel in the
>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>
>>>
>>> j)
>>> Split camel-cxf into modules so we can separate WS and RS and also
>>> spring vs blueprint. Today its big ball of dependencies that is a bit
>>> hard to slice and dice. Specially for MSA style with REST and you dont
>>> want to add in a bunch of extra not needed JARs.
>>>
>>>
>>> k)
>>> Continue as usual by adding new components, data formats, fix bugs, and so on.
>>>
>>>
>>> l)
>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>> could try to get this "stepping stone" release done sooner, so it can
>>> be released during/shortly after summer.
>>>
>>> There is plenty of "first work" that we must do with the java 8
>>> upgrade and dropping older techs etc, that we have our hands full for
>>> a while.
>>>
>>> Doing a release with these changes allows our end users to migrate
>>> along in a easy way, than a big bang - breaking apis - release would
>>> do. And the latter would be more appropriate to be released as Camel
>>> 3.0.
>>>
>>> Then towards the end of this year, we can see where we are and plan
>>> for a Camel 3.0 with a new website and documentation that such a
>>> release deserve. For example if we release Camel 3.0 in start of 2017
>>> then its also Camel's 10 year birthday year.
>>>
>>> And doing such a release with a rewamped website with fresh looking
>>> documentation and content, is what helps the project a lot.
>>>
>>> The current website looks the same as it did when it was created:
>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>
>>> PS: We surely also need a better "what is Camel" story on the front
>>> page. Its still that very first one with all the tech jumble that was
>>> initially created.
>>>
>>> PPS: I would also love to see a new Camel logo. The current one is a
>>> bit dull and boring.
>>>
>>>
>>>
>>>
>> --
>> 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/)
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Matt Pavlovich
In reply to this post by Raul Kripalani-3


On 3/24/16 3:27 PM, Raul Kripalani wrote:

> On Thu, Mar 24, 2016 at 5:24 PM, Krzysztof Sobkowiak <
> [hidden email]> wrote:
>
>> I think, the way to Camel 3 should also include the renovation of the Core
>> (if really necessary) or even rewriting and
>> making it more asynchronous, e.g. using rx.java (the later can be
>> eventually part of Camel 4 roadmap if too dangerous
>> for Camel 3).
>>
> This also relates to the concurrency model. Camel revolves around the idea
> that more threads == more performance. Our processing actually
> hijacks/piggy-backs the threads of the 3rd party library of the component
> (Netty, Jetty, Spring JMS, etc. threads), and this is not good. One just
> needs to look around: reactive programming, coroutines, event loops,
> generators, goroutines (in Go), etc. to realise we're kinda obsolete by now.
"Obsolete" by what standard?
> The async routing engine was a step in the right direction, but most
> components don't even support it.
>
> Now that we know the reactive programming model is here to stay and it
> wasn't a fad, I feel we should definitely go in that direction. We should
> look at Akka, RxJava and the Reactive Streams [3] spec.
I expect there will be long term valuable pieces pulled from reactive
programming, just as there are from virtually every new "paradigm" that
pops up every few years-- but there will also be a balance of "doesn't
meet the hype". Anyone remember AOP (Btw-- which now has 3-4
sub-derivatives)?  I suggest letting the dust settle to see what the
benefits-tradeoffs matrix looks like before committing to overhauling
Camel core.

-Matt
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Matt Pavlovich
In reply to this post by Claus Ibsen-2
On 3/23/16 5:07 AM, Claus Ibsen wrote:
> j)
> Split camel-cxf into modules so we can separate WS and RS and also
> spring vs blueprint. Today its big ball of dependencies that is a bit
> hard to slice and dice. Specially for MSA style with REST and you dont
> want to add in a bunch of extra not needed JARs.
+1
> l)
> Timeline. This release do not need to have 6-8 months timeframe. We
> could try to get this "stepping stone" release done sooner, so it can
> be released during/shortly after summer.
I think this is a great idea. OSS projects can get bogged down with
ambitious "let's fix everything" goals.
The goals laid out here would setup a great foundation for 3.x to have a
nice run and plenty of room to add sugar.

> And doing such a release with a rewamped website with fresh looking
> documentation and content, is what helps the project a lot.
>
> The current website looks the same as it did when it was created:
> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
I thought the Karaf guys did a nice job on the website re-work. Is there
a new base framework for all Apache projects, or are we at ground zero
on this?

> PS: We surely also need a better "what is Camel" story on the front
> page. Its still that very first one with all the tech jumble that was
> initially created.
I'm up for helping-- will ping jkorab to coordinate.

> PPS: I would also love to see a new Camel logo. The current one is a
> bit dull and boring.
+1

-Matt

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Johan Edstrom-2
In reply to this post by Matt Pavlovich
I think the core should focus on speed, consistency, reliability
and last extensibility; Camel has a nice traction but we don’t
want to see “strange” bugs from new features if that makes
sense as a long windy sentence…..



> On Apr 4, 2016, at 9:36 AM, Matt Pavlovich <[hidden email]> wrote:
>
>
>
> On 3/24/16 3:27 PM, Raul Kripalani wrote:
>> On Thu, Mar 24, 2016 at 5:24 PM, Krzysztof Sobkowiak <
>> [hidden email]> wrote:
>>
>>> I think, the way to Camel 3 should also include the renovation of the Core
>>> (if really necessary) or even rewriting and
>>> making it more asynchronous, e.g. using rx.java (the later can be
>>> eventually part of Camel 4 roadmap if too dangerous
>>> for Camel 3).
>>>
>> This also relates to the concurrency model. Camel revolves around the idea
>> that more threads == more performance. Our processing actually
>> hijacks/piggy-backs the threads of the 3rd party library of the component
>> (Netty, Jetty, Spring JMS, etc. threads), and this is not good. One just
>> needs to look around: reactive programming, coroutines, event loops,
>> generators, goroutines (in Go), etc. to realise we're kinda obsolete by now.
> "Obsolete" by what standard?
>> The async routing engine was a step in the right direction, but most
>> components don't even support it.
>>
>> Now that we know the reactive programming model is here to stay and it
>> wasn't a fad, I feel we should definitely go in that direction. We should
>> look at Akka, RxJava and the Reactive Streams [3] spec.
> I expect there will be long term valuable pieces pulled from reactive programming, just as there are from virtually every new "paradigm" that pops up every few years-- but there will also be a balance of "doesn't meet the hype". Anyone remember AOP (Btw-- which now has 3-4 sub-derivatives)?  I suggest letting the dust settle to see what the benefits-tradeoffs matrix looks like before committing to overhauling Camel core.
>
> -Matt

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Raul Kripalani-3
In reply to this post by Matt Pavlovich
On Mon, Apr 4, 2016 at 4:44 PM, Matt Pavlovich <[hidden email]> wrote:

> The current website looks the same as it did when it was created:
>>
>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>
> I thought the Karaf guys did a nice job on the website re-work. Is there a
> new base framework for all Apache projects, or are we at ground zero on
> this?


I dig the Karaf redesign - clean, modern and simple. I'd love to aim for
something similar in Camel.

What do we do about our content editing system? My proposal is to move away
from Confluence and adopt Markdown, AsciiDoc, or the like.

Pros:

1. Docs can be versioned alongside code
2. The HTML is purer and with less artifacts => accurate styling => cleaner
visuals.
3. A breeze to edit, fix typos, add release notes, etc.

Cons:

1. Large migration effort.

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
<http://raul.io/?utm_source=email&utm_medium=email&utm_campaign=apache> |
twitter: @raulvk <https://twitter.com/raulvk>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Matt Pavlovich


On 4/4/16 11:12 AM, Raul Kripalani wrote:

> On Mon, Apr 4, 2016 at 4:44 PM, Matt Pavlovich <[hidden email]> wrote:
>
>> The current website looks the same as it did when it was created:
>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>
>> I thought the Karaf guys did a nice job on the website re-work. Is there a
>> new base framework for all Apache projects, or are we at ground zero on
>> this?
>
> I dig the Karaf redesign - clean, modern and simple. I'd love to aim for
> something similar in Camel.
>
> What do we do about our content editing system? My proposal is to move away
> from Confluence and adopt Markdown, AsciiDoc, or the like.
>
> Pros:
>
> 1. Docs can be versioned alongside code
> 2. The HTML is purer and with less artifacts => accurate styling => cleaner
> visuals.
> 3. A breeze to edit, fix typos, add release notes, etc.
>
> Cons:
>
> 1. Large migration effort.

I agree, a markdown-based CMS would be handy. Do we know what Karaf is
using?

Re Cons #1: I think the docs need a massive overhaul anyway. Probably a
good time to just do it.

The component config should be separated by version and not a
hodge-podge of carve-outs like we have today.

Rough pass at a TOC:
(Suggest short and sweet)
Index
Documentation
Download
Support

Then the sub-sections fall under the top level categories.

Documentation
    + Core
    + Components
    + Data Formats
    + etc..

Download
     + Grab the bits
     + Grab the source
     + Links to svn / git etc

Contributor Documentation
     + Camel API
     + etc..

Support
      + Community  ( IRC, mailing lists, LinkedIn Group, etc)
      + Commercial


>
> 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
> <http://raul.io/?utm_source=email&utm_medium=email&utm_campaign=apache> |
> twitter: @raulvk <https://twitter.com/raulvk>
>

123