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

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

Claus Ibsen-2
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
Reply | Threaded
Open this post in threaded view
|

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

Deven Phillips
For the logo, I think that my wife (a graphic artist) might be looking for
just that kind of challenge... I will let you know once I discuss it with
her.

I assume that she will need to submit an ICLA for the work?

Deven

On Wed, Mar 23, 2016 at 6: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
>
Reply | Threaded
Open this post in threaded view
|

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

Claus Ibsen-2
On Wed, Mar 23, 2016 at 1:43 PM, Deven Phillips
<[hidden email]> wrote:
> For the logo, I think that my wife (a graphic artist) might be looking for
> just that kind of challenge... I will let you know once I discuss it with
> her.
>

Yeah sounds great. Would be great to have professionals sketch logos,
so we have a great looking logo.
And I think most of us would like to see a Camel animal in the logo
and they are not so easy to sketch by amateurs.


> I assume that she will need to submit an ICLA for the work?
>

That is actually a good question. But yeah some form of "agreement"
from the artist to ASF so the "work of art" is handed over to ASF. For
any other kind of contributions that is the ICLA. So I would really
assume it would be the same for graphical work.

Anyone have more knowledge on this?


> Deven
>
> On Wed, Mar 23, 2016 at 6: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

jkorab
In reply to this post by Claus Ibsen-2
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
Reply | Threaded
Open this post in threaded view
|

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

Claus Ibsen-2
On Wed, Mar 23, 2016 at 3:22 PM, jkorab <[hidden email]> 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
>

Yes that would be great. We should start there, and then eventually
improve or re-write those getting started sections of the
documentation.

And clean up other sections too, there is some old tutorials and
guides that no longer apply and a bunch of other stuff. But all that
should be part of the new documentation and website effort.

But we could surely still use a better "what is Camel" explanation on
the current front page. Instead of waiting until 3.0.



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



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

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
Reply | Threaded
Open this post in threaded view
|

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

astefanutti
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

Reply | Threaded
Open this post in threaded view
|

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

Andrea Cosentino-2
In reply to this post by Claus Ibsen-2
For the docs part, we are at almost half of the components in this moment.

I hope we can finish them soon.
 --
Andrea Cosentino
----------------------------------
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: [hidden email]
Twitter: @oscerd2
Github: oscerd



On Wednesday, March 23, 2016 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
Reply | Threaded
Open this post in threaded view
|

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

Gnanaguru S

Guys,

These are some of the feature, I wish to see in upcoming camel versions. It would be useful to have.

1. Timeout option in a internal synchronous endpoint - we very much use camel for orchestration layer. In a use case where many downstream routes/endpoints are called synchronously, I would like to have a direct: endpoint which has a timeout. So that I can timeout a call to some particular downstream route, handle the exception and proceed to the next step. In fact this option is already there with seda: endpoint, but I wont prefer to use seda: for synchronous flow. Also I can use internal JMS endpoints between routes to achieve this, but sometimes using JMS for internal transaction is heavy.

2. Improved/Sophisticated xmljson component.

3. Improved/even Simpler exception handling.

4. Native Camel transformation component, I am bit obsessed with XSLT. So I was thinking, why dont camel   incorporate something like xslt: internally. like Camel transformer component ? Something better than XSLT component, something very camelish. ;)

5. Better CXF configurations, for example configuring timeout for a cxf consumer and producer endpoint is not that straight forward like jetty / http(4) components.

6. Better/Improved unit testing, Camel test support is great, like AdviceWith & Mock endpoints. But some of their methods have issues, I am seeing latest camel versions have lot of fixes, but I think some more features can be introduced. For example, if I want send a sample XML as a request, I dont want to use a IOUtil or a File reader to load the file and then to a string and then pass it to a producer template, instead it will be easier if there is a something called as mockRequest. May be there are better options already, please ignore my ignorance here ;)

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

8. Ability to load a route context directly to a unit test case

These are some aspects I could think of at the moment, I will try to add more. But please ignore if some of these ideas sounds silly ;)

Happy long weekend !

Cheers
Guru
http://gnan.io

Reply | Threaded
Open this post in threaded view
|

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

Quinn Stevenson
In reply to this post by astefanutti
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
>

Reply | Threaded
Open this post in threaded view
|

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

Claus Ibsen-2
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
Reply | Threaded
Open this post in threaded view
|

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

Quinn Stevenson
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?

> 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

Reply | Threaded
Open this post in threaded view
|

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

Claus Ibsen-2
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
>



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

sobkowiak
In reply to this post by Claus Ibsen-2
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).

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

Raul Kripalani-3
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).
>

What a coincidence! This thought crossed my mind today. Indeed the core of
Camel has become too complicated in terms of how the moving parts stick
together.

A long time ago I had serious concerns about how deep the stack traces have
become, with Channels, Interceptors, helpers, and what not, and I proposed
an iterative, horizontally-expanding, pipeline-based model for the core
routing rather than a vertically-expanding, deep stack traces model.

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.

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.

In an ideal world, we would reimplement the core of Camel based on the
principles of Reactive Programming and/or Actors. That's assuming we want
to stay on the JVM (:D), because the use case of Camel ties it pretty well
with the concurrency constructs of Go.

[1] http://akka.io/
[2] https://github.com/ReactiveX/RxJava
[3] http://www.reactive-streams.org/

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
Blog: raul.io | twitter: @raulvk <https://twitter.com/raulvk>
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 sobkowiak
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.

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.


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.

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



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

Raul Kripalani-3
On Thu, Mar 24, 2016 at 8:55 PM, Claus Ibsen <[hidden email]> wrote:

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

A camel-rx component is an experiment rather than a component with a real
use-case backing, IMHO. It's hard to find a use case for it.

We're talking about different things. To me, Reactive is not a "module":
it's a core pattern that you adopt in order to deal with inputs, data
streams, RPC calls and concurrency. We're talking about *becoming* reactive
at the heart to improve how we deal with concurrency and streams, not about
little accessory.

About Camel not being "in the forefront": that depends on the use case. For
most of my customers, Camel is a at the heart of their ESB and it is a
crucial component in their Enterprise Architecture. In some cases, Camel
serves an API consumed by a public customer-facing site.

Hence, I don't think we can generalise, and we don't have any survey
numbers (AFAIK) to make any assertions about our users. Nor should we make
assumptions based on what we see or not in the mailing lists or
StackOverflow or other forums. Some people are more vocal when asking for
help than others, so extracting information based on what one sees is
vulnerable to a large set of biases.

Back to the topic: I agree rewriting the core (whether in one direction or
another) is a massive undertaking and not feasible for Camel 3. But rather
than stopping the conversation at "let's push it to Camel 4", I'd like to
hear people's thoughts. If the community wants to go in this direction at
some point, we gotta start assembling interest.

Does anybody feel strongly about this too?

Cheers,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
Blog: raul.io | twitter: @raulvk <https://twitter.com/raulvk>
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 Gnanaguru S
Hey Guru,

Nice ideas! Some thoughts inline.

Cheers,
Raúl.

On Thu, Mar 24, 2016 at 12:12 PM, Gnanaguru S <[hidden email]> wrote:

>
> Guys,
>
> These are some of the feature, I wish to see in upcoming camel versions. It
> would be useful to have.
>
> 1. Timeout option in a internal synchronous endpoint - we very much use
> camel for orchestration layer. In a use case where many downstream
> routes/endpoints are called synchronously, I would like to have a direct:
> endpoint which has a timeout. So that I can timeout a call to some
> particular downstream route, handle the exception and proceed to the next
> step. In fact this option is already there with seda: endpoint, but I wont
> prefer to use seda: for synchronous flow. Also I can use internal JMS
> endpoints between routes to achieve this, but sometimes using JMS for
> internal transaction is heavy.
>

Yep. JMS can be a little heavy, but I tend to go in that direction for
internal orchestration because it supports the async routing engine. For
us, it is very important to not block the system while we're waiting for
backend systems to respond. I think that camel-seda and camel-disruptor
need to support the async routing engine. I might work on this in the next
weeks. You can use camel-seda with waitForTaskToComplete=Always, or it'll
work OOTB if your exchange is InOut (default value of the option is
'IfReplyExpected').

2. Improved/Sophisticated xmljson component.
>

We depend on a 3rd party library for this. Do you know if there's a better
3rd party library for this?


> 3. Improved/even Simpler exception handling.
>

Could you detail this point? I think we need to simplify the documentation
for error handling. In most cases I've seen, 100% of the users requirements
is satisfied by onException.
A suggestion from my part is to find a way to use onExceptions defined at
the context level without copying them to each single route (wasteful,
imagine if you're using a recipientList with its corresponding producer
cache, etc.).


> 4. Native Camel transformation component, I am bit obsessed with XSLT. So I
> was thinking, why dont camel   incorporate something like xslt: internally.
> like Camel transformer component ? Something better than XSLT component,
> something very camelish. ;)
>

So am I ;-) If you come from a comercial ESB background, you're likely to
find lots of potential in externally declared transformations vs. code
transformations.
What would be cool is to be able to inject, delete, modify XML nodes and
attributes directly from a route, without dealing with XML APIs, with
specific DSL particles.
What exactly were you thinking of?


> 5. Better CXF configurations, for example configuring timeout for a cxf
> consumer and producer endpoint is not that straight forward like jetty /
> http(4) components.
>
> 6. Better/Improved unit testing, Camel test support is great, like
> AdviceWith & Mock endpoints. But some of their methods have issues, I am
> seeing latest camel versions have lot of fixes, but I think some more
> features can be introduced. For example, if I want send a sample XML as a
> request, I dont want to use a IOUtil or a File reader to load the file and
> then to a string and then pass it to a producer template, instead it will
> be
> easier if there is a something called as mockRequest. May be there are
> better options already, please ignore my ignorance here ;)
>
> 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.


>
> 8. Ability to load a route context directly to a unit test case
>
> These are some aspects I could think of at the moment, I will try to add
> more. But please ignore if some of these ideas sounds silly ;)
>
> Happy long weekend !
>
> Cheers
> Guru
> http://gnan.io
>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/DISCUSS-Thoughts-on-Apache-Camel-2-18-and-towards-3-0-tp5779549p5779641.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

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

Walzer, Thomas
Regarding Raul´s ideas: Change often frightens people and changing the engine of a work horse (err, I mean work camel) surely frightens me. Maybe I am a worrisome person.
I really like to be able to at least look at the moving parts. If you move to Rx/Go/Scala/whatever (right now) you have surely lost me. That will change in the future.
Maybe waiting for the new (ok, maybe not so new) ideas to trickle (a bit more) into the mainstream would be a good idea.
The project is called Apache Camel not Apache Fighterjet for a reason :-)

If this is kind of a wish list and to add a bit of a user´s perspective: I have to deal with obscure data formats on a daily basis. Sometimes they are parseable with Beanio and the like but oftentimes they are not. Yes, one could roll his own, but I would really prefer not to.
I would really love to have a universal parser (like the one that was included with Seebeyond/sun/oracle JCAPS/egate). I understand that smooks was there to solve this but to me it looks dead. But the discussion of this aspect should go to the users-list. I will start a separate thread there.

Cheers, Thomas.

PS: Ok, the reason for the name may have more to do with a certain habit of a certain guy.

-----Ursprüngliche Nachricht-----
Von: Raul Kripalani [mailto:[hidden email]]
Gesendet: Donnerstag, 24. März 2016 22:40
An: [hidden email]
Betreff: Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Hey Guru,

Nice ideas! Some thoughts inline.

Cheers,
Raúl.

On Thu, Mar 24, 2016 at 12:12 PM, Gnanaguru S <[hidden email]> wrote:

>
> Guys,
>
> These are some of the feature, I wish to see in upcoming camel
> versions. It would be useful to have.
>
> 1. Timeout option in a internal synchronous endpoint - we very much
> use camel for orchestration layer. In a use case where many downstream
> routes/endpoints are called synchronously, I would like to have a direct:
> endpoint which has a timeout. So that I can timeout a call to some
> particular downstream route, handle the exception and proceed to the
> next step. In fact this option is already there with seda: endpoint,
> but I wont prefer to use seda: for synchronous flow. Also I can use
> internal JMS endpoints between routes to achieve this, but sometimes
> using JMS for internal transaction is heavy.
>

Yep. JMS can be a little heavy, but I tend to go in that direction for internal orchestration because it supports the async routing engine. For us, it is very important to not block the system while we're waiting for backend systems to respond. I think that camel-seda and camel-disruptor need to support the async routing engine. I might work on this in the next weeks. You can use camel-seda with waitForTaskToComplete=Always, or it'll work OOTB if your exchange is InOut (default value of the option is 'IfReplyExpected').

2. Improved/Sophisticated xmljson component.
>

We depend on a 3rd party library for this. Do you know if there's a better 3rd party library for this?


> 3. Improved/even Simpler exception handling.
>

Could you detail this point? I think we need to simplify the documentation for error handling. In most cases I've seen, 100% of the users requirements is satisfied by onException.
A suggestion from my part is to find a way to use onExceptions defined at the context level without copying them to each single route (wasteful, imagine if you're using a recipientList with its corresponding producer cache, etc.).


> 4. Native Camel transformation component, I am bit obsessed with XSLT. So I
> was thinking, why dont camel   incorporate something like xslt: internally.
> like Camel transformer component ? Something better than XSLT
> component, something very camelish. ;)
>

So am I ;-) If you come from a comercial ESB background, you're likely to find lots of potential in externally declared transformations vs. code transformations.
What would be cool is to be able to inject, delete, modify XML nodes and attributes directly from a route, without dealing with XML APIs, with specific DSL particles.
What exactly were you thinking of?


> 5. Better CXF configurations, for example configuring timeout for a
> cxf consumer and producer endpoint is not that straight forward like
> jetty /
> http(4) components.
>
> 6. Better/Improved unit testing, Camel test support is great, like
> AdviceWith & Mock endpoints. But some of their methods have issues, I
> am seeing latest camel versions have lot of fixes, but I think some
> more features can be introduced. For example, if I want send a sample
> XML as a request, I dont want to use a IOUtil or a File reader to load
> the file and then to a string and then pass it to a producer template,
> instead it will be easier if there is a something called as
> mockRequest. May be there are better options already, please ignore my
> ignorance here ;)
>
> 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.


>
> 8. Ability to load a route context directly to a unit test case
>
> These are some aspects I could think of at the moment, I will try to
> add more. But please ignore if some of these ideas sounds silly ;)
>
> Happy long weekend !
>
> Cheers
> Guru
> http://gnan.io
>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/DISCUSS-Thoughts-on-Apache-Camel-2-1
> 8-and-towards-3-0-tp5779549p5779641.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

Antoine Toulme-2
In reply to this post by Claus Ibsen-2
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


smime.p7s (4K) Download Attachment
123