You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2016/03/23 11:07:08 UTC
[DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Mar 24, 2016 at 1:12 PM, Gnanaguru S <gn...@gmail.com> 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.
>
> 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 ;)
>
You can send a java.io.File as the message body in the producer template.
> 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
>
>
>
>
>
> --
> 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.
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Andreas Gebhardt <ag...@googlemail.com>.
> Yeah sure we love contributions.
Awesome - I create a 'Wish' issue on JIRA (CAMEL-9799) to be transparency.
There are two implementations mentioned on JSON Schema [1],
'json-schema-validator' [2] which is created by (one of) the authors of
JSON Schema and 'json-schema' [3].
Both seems to be compatible with the Apache 2 license. Are there any
thoughts to use either [2] or [3] or should there be a extra layer to
choose by ourself?
> Just wonder if swagger can be used instead of raml? swagger is much
> more popular.
>
> Swagger is now run under an independt organization
> https://openapis.org/specification
You are absolutely right.
We started with Swagger and run into trouble with the annotation based
documentation. The API exposes and consumes resources as JSON. There is
a check/validation process of incoming JSON resources against the
appropriate JSON Schema so we we can rely on mandatory fields without
testing each time. With RAML we can use these schemas without any
adoption. Also the 'Consumer Driven Contracts' [4] pattern goes smoothly
hand-in-hand with support by other 3rd party tools.
[1] http://json-schema.org/implementations.html
[2] https://github.com/fge/json-schema-validator
[3] https://github.com/everit-org/json-schema
[4] http://www.martinfowler.com/articles/consumerDrivenContracts.html
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Apr 1, 2016 at 8:56 PM, Andreas Gebhardt
<ag...@googlemail.com> wrote:
> Hi,
>
>>> 7. JSON validator. XML XSD validation is nice and straight forward, but
>>> it
>>> will be great if we have something similar for JSON as well. like
>>> to:json-validator:classpath/response.json
>>>
>>
>> Yep, we should create a component for JSON Schema validations.
>
>
> I would like to contribute to this (new) component. We use JSON Schema [1]
> successfully at work to describe requests and responses for a RESTfull API
> in combination with RAML [2].
>
> I would create an task (improvement) on Camel's JIRA and start with an
> prototype. Is this okay?
>
> Best Andreas
>
> [1] http://json-schema.org/
> [2] http://raml.org/
Yeah sure we love contributions.
Just wonder if swagger can be used instead of raml? swagger is much
more popular.
Swagger is now run under an independt organization
https://openapis.org/specification
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Andreas Gebhardt <ag...@googlemail.com>.
Hi,
>> 7. JSON validator. XML XSD validation is nice and straight forward, but it
>> will be great if we have something similar for JSON as well. like
>> to:json-validator:classpath/response.json
>>
>
> Yep, we should create a component for JSON Schema validations.
I would like to contribute to this (new) component. We use JSON Schema
[1] successfully at work to describe requests and responses for a
RESTfull API in combination with RAML [2].
I would create an task (improvement) on Camel's JIRA and start with an
prototype. Is this okay?
Best Andreas
[1] http://json-schema.org/
[2] http://raml.org/
AW: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by "Walzer, Thomas" <th...@integratix.net>.
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:raulk@apache.org]
Gesendet: Donnerstag, 24. März 2016 22:40
An: dev@camel.apache.org
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 <gn...@gmail.com> 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.
>
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Raul Kripalani <ra...@apache.org>.
Hey Guru,
Nice ideas! Some thoughts inline.
Cheers,
Raúl.
On Thu, Mar 24, 2016 at 12:12 PM, Gnanaguru S <gn...@gmail.com> 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.
>
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Gnanaguru S <gn...@gmail.com>.
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
--
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.
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Andrea Cosentino <an...@yahoo.com.INVALID>.
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: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Wednesday, March 23, 2016 11:07 AM, Claus Ibsen <cl...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Mar 23, 2016 at 1:43 PM, Deven Phillips
<de...@gmail.com> 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 <cl...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Deven Phillips <de...@gmail.com>.
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 <cl...@gmail.com> 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
>
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
There was a comment on my blog about the Camel logo
Hey Claus; The OpenTSDB project (http://opentsdb.net/) ran an icon
design contest on 99designs. People submit designs and others vote.
It's a cool system and I imagine you would get a lot of
submissions....
On Wed, Mar 23, 2016 at 11:07 AM, Claus Ibsen <cl...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
On 01.04.2016 09:17, Claus Ibsen wrote:
> Hi
>
> On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> I recently worked on some projects that also need OSGi settings and found an
>> interesting thing.
>> It seems the easiest way to get the exports, imports and other OSGi settings
>> right is not to use central defaults and instead do all settings per project
>> while relying on defaults as much as possible.
>>
> Christian is the wording correct? I read this a bit like "do not use
> central defaults" and then "rely on default as much as possible" are
> they not the opposite?
>
> Do you mean do not use central defaults. And if you must then as
> little as possible?
Sorry .. that was a bit confusing.
What I mean is. I do not set defaults in the parent pom and instead rely
on the defaults of bnd. From this base I apply the necessary settings in
each bnd.bnd file
but in the most minimal way that works.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by David Jencks <da...@yahoo.com.INVALID>.
I’d suggest replacing the obsolete Import-Service and Export-Service with actually useful Require-Capability and Provide-Capability headers.
david jencks
> On Apr 1, 2016, at 7:01 AM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>
> One clarification on the bnd-maven-plugin configuration - it will inherit configuration from parent bnd.bnd files, so we can have the common configuration we want in the top-level directory, and only override it when needed.
>
> Also - there are some “information only” headers in put in the MANIFEST.MF now (like Import-Service and Export-Service) - do we need those?
>
> As Christian said, the tools do a very good job of calculating imported packages. Depending on what we want exported, the Export-Package header may be configured globally as well.
>
>> On Apr 1, 2016, at 1:17 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>
>> Hi
>>
>> On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider
>> <chris@die-schneider.net <ma...@die-schneider.net>> wrote:
>>> I recently worked on some projects that also need OSGi settings and found an
>>> interesting thing.
>>> It seems the easiest way to get the exports, imports and other OSGi settings
>>> right is not to use central defaults and instead do all settings per project
>>> while relying on defaults as much as possible.
>>>
>>
>> Christian is the wording correct? I read this a bit like "do not use
>> central defaults" and then "rely on default as much as possible" are
>> they not the opposite?
>>
>> Do you mean do not use central defaults. And if you must then as
>> little as possible?
>>
>>
>>
>>
>>> I use these settings in the parent:
>>> https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L199-L223
>>>
>>> So basically what I do is to only activate the bundle plugin in the parent
>>> and set it to not auto export packages. For bnd-maven-plugin this should not
>>> be necessary as it is the default.
>>> I then delegate the OSGi settings to a bnd.bnd file. This is largely equal
>>> to the pom config but a little less verbose.
>>>
>>> An example can be found at:
>>> https://github.com/apache/aries-rsa/tree/master/rsa
>>> https://github.com/apache/aries-rsa/blob/master/rsa/bnd.bnd
>>>
>>> As you see the pom of each project contains no OSGi informations at all and
>>> the bnd.bnd files are very small.
>>> So I would recommend this approach for camel too.
>>>
>>
>> Ah so instead of having osgi stuff mixed around in parent central pom
>> files, and then with some overlays in current pom.xml, you are solely
>> using a bnd.bnd file per module.
>>
>> So that would mean we would need to do a bnd.bnd file per Camel module
>> that is an OSGi bundle?
>> And how much do you need to configure those bnd.bnd files? Today we
>> get the import|export generated.
>>
>>
>>> Christian
>>>
>>>
>>> On 24.03.2016 16:18, Claus Ibsen wrote:
>>>>
>>>> On Thu, Mar 24, 2016 at 4:10 PM, Quinn Stevenson
>>>> <qu...@pronoia-solutions.com> 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 <cl...@gmail.com> 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
>>>>>> <qu...@pronoia-solutions.com> 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
>>>>>>>> <an...@stefanutti.fr> 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 <cl...@gmail.com> 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 <cl...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> So Camel 2.17 was the last release supporting Java 1.7.
>>>>>>>>>> The next Camel 2.18 is requiring Java 1.8.
>>>>>>>>>>
>>>>>>>>>> Here is some thoughts of mine about this release up for discussion.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> a)
>>>>>>>>>> I see the overall goal of Camel 2.18 as a stepping stone towards
>>>>>>>>>> Java
>>>>>>>>>> 1.8 and Camel 3.0.
>>>>>>>>>>
>>>>>>>>>> By that I mean the release should be a way of moving our existing
>>>>>>>>>> users from Java 1.7 and the current Camel APIs and the likes
>>>>>>>>>> gradually
>>>>>>>>>> towards Java 1.8 and eventually Camel 3.0.
>>>>>>>>>>
>>>>>>>>>> In other words we should not get carried away to change/break APIs
>>>>>>>>>> and
>>>>>>>>>> whatnot just because Java 1.8 lambdas and functions.
>>>>>>>>>>
>>>>>>>>>> There are too many current users that rely on the current Camel API
>>>>>>>>>> and we cannot go around change processor / expression / predicate /
>>>>>>>>>> aggregation strategy and other interfaces to be java 8 functional if
>>>>>>>>>> that means current code cannot compile. And certainly not adding
>>>>>>>>>> Optional<X> as return types all over.
>>>>>>>>>>
>>>>>>>>>> The following releases (Camel 2.19 or 3.0) can pick up that torch
>>>>>>>>>> and
>>>>>>>>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>>>>>>>>> changes that are Java 8 lambda / functional based. And as well
>>>>>>>>>> changes
>>>>>>>>>> in the DSL to go with that.
>>>>>>>>>>
>>>>>>>>>> There are some minor code changes needed to make the source compile
>>>>>>>>>> as
>>>>>>>>>> source 1.8 to go in this Camel 2.18 let alone.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> b)
>>>>>>>>>> Drop components that do not support and run on Java 1.8
>>>>>>>>>> And potentially remove some deprecated components
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> c)
>>>>>>>>>> Drop karaf 2.x.
>>>>>>>>>> And move to karaf 4.x for all our testing.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> d)
>>>>>>>>>> Drop Jetty 8.x.
>>>>>>>>>>
>>>>>>>>>> This also requires to upgrade at least two components that currently
>>>>>>>>>> rely on Jetty 8 to use Jetty 9.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> e)
>>>>>>>>>> Upgrade to latest Jetty 9.
>>>>>>>>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> f)
>>>>>>>>>> Drop support for older versions of Spring. We have a number of
>>>>>>>>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>>>>>>>>> spring 4.0. as its also EOL.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> g)
>>>>>>>>>> Potentially move spring-dm out of camel-spring into a
>>>>>>>>>> camel-spring-dm
>>>>>>>>>> module. So camel-spring can use latest version of Spring safely.
>>>>>>>>>> This
>>>>>>>>>> also makes it easier to deprecated spring-dm and remove it
>>>>>>>>>> eventually.
>>>>>>>>>> The Karaf team is working on a sping -> blueprint layer so you can
>>>>>>>>>> use
>>>>>>>>>> spring xml files but Karaf will "convert" that under the hood to
>>>>>>>>>> blueprint and run it as blueprint. When that is ready we no longer
>>>>>>>>>> need spring-dm.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> h)
>>>>>>>>>> Continue adding components docs in the source, eg src/main/doc
>>>>>>>>>> files.
>>>>>>>>>> So we eventually have as many/all of them. This is an ongoing
>>>>>>>>>> effort,
>>>>>>>>>> as we need to do this for the EIPs and the other parts of the docs.
>>>>>>>>>>
>>>>>>>>>> However I see this as a great step for a new documentation and
>>>>>>>>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>>>>>>>>> website fresh and modern. And make the documentation easier for end
>>>>>>>>>> users to use and view.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> i)
>>>>>>>>>> Add camel-hysterix component and integrate camel's circuit breaker
>>>>>>>>>> into turbine/hysterix so you can see metrics from camel in the
>>>>>>>>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> j)
>>>>>>>>>> Split camel-cxf into modules so we can separate WS and RS and also
>>>>>>>>>> spring vs blueprint. Today its big ball of dependencies that is a
>>>>>>>>>> bit
>>>>>>>>>> hard to slice and dice. Specially for MSA style with REST and you
>>>>>>>>>> dont
>>>>>>>>>> want to add in a bunch of extra not needed JARs.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> k)
>>>>>>>>>> Continue as usual by adding new components, data formats, fix bugs,
>>>>>>>>>> and so on.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> l)
>>>>>>>>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>>>>>>>>> could try to get this "stepping stone" release done sooner, so it
>>>>>>>>>> can
>>>>>>>>>> be released during/shortly after summer.
>>>>>>>>>>
>>>>>>>>>> There is plenty of "first work" that we must do with the java 8
>>>>>>>>>> upgrade and dropping older techs etc, that we have our hands full
>>>>>>>>>> for
>>>>>>>>>> a while.
>>>>>>>>>>
>>>>>>>>>> Doing a release with these changes allows our end users to migrate
>>>>>>>>>> along in a easy way, than a big bang - breaking apis - release would
>>>>>>>>>> do. And the latter would be more appropriate to be released as Camel
>>>>>>>>>> 3.0.
>>>>>>>>>>
>>>>>>>>>> Then towards the end of this year, we can see where we are and plan
>>>>>>>>>> for a Camel 3.0 with a new website and documentation that such a
>>>>>>>>>> release deserve. For example if we release Camel 3.0 in start of
>>>>>>>>>> 2017
>>>>>>>>>> then its also Camel's 10 year birthday year.
>>>>>>>>>>
>>>>>>>>>> And doing such a release with a rewamped website with fresh looking
>>>>>>>>>> documentation and content, is what helps the project a lot.
>>>>>>>>>>
>>>>>>>>>> The current website looks the same as it did when it was created:
>>>>>>>>>>
>>>>>>>>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>>>>>>>>
>>>>>>>>>> PS: We surely also need a better "what is Camel" story on the front
>>>>>>>>>> page. Its still that very first one with all the tech jumble that
>>>>>>>>>> was
>>>>>>>>>> initially created.
>>>>>>>>>>
>>>>>>>>>> PPS: I would also love to see a new Camel logo. The current one is a
>>>>>>>>>> bit dull and boring.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Claus Ibsen
>>>>>>>>>> -----------------
>>>>>>>>>> http://davsclaus.com @davsclaus
>>>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Claus Ibsen
>>>>>>>>> -----------------
>>>>>>>>> http://davsclaus.com @davsclaus
>>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> -----------------
>>>>>> http://davsclaus.com @davsclaus
>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
On 01.04.2016 16:01, Quinn Stevenson wrote:
> One clarification on the bnd-maven-plugin configuration - it will inherit configuration from parent bnd.bnd files, so we can have the common configuration we want in the top-level directory, and only override it when needed.
>
> Also - there are some “information only” headers in put in the MANIFEST.MF now (like Import-Service and Export-Service) - do we need those?
The Import-Service and Export-Service headers are not only for
information. They are actually used at resolve time in karaf. Even more
karaf 4 by default applies a strict validation
that for all services that are imported there is also an export. This is
not defined in the OSGi specs and can also be switched off in karaf. It
only applies though if we use the new
1.3.0 feature namespace.
As David wrote it makes sense to use the Capability headers instead of
the service ones. As creating those headers by hand is quite a lot of
effort I think we need to automate this process.
I created an issue for this a long time ago but never actually got it
implemented. See https://issues.apache.org/jira/browse/CAMEL-8046
>
> As Christian said, the tools do a very good job of calculating imported packages. Depending on what we want exported, the Export-Package header may be configured globally as well.
For import I agree it should be done as automated as possible. Normally
it should not be necessary to set global defaults for it.
For exports it depends how clean the design is. In an ideal OSGi design
you would normally export. bnd can help with this by a new setting that
only exports packages that also define a package version.
In Camel though users access a lot of the implementations too. So maybe
the simplest thing is to export all packages by default.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
One clarification on the bnd-maven-plugin configuration - it will inherit configuration from parent bnd.bnd files, so we can have the common configuration we want in the top-level directory, and only override it when needed.
Also - there are some “information only” headers in put in the MANIFEST.MF now (like Import-Service and Export-Service) - do we need those?
As Christian said, the tools do a very good job of calculating imported packages. Depending on what we want exported, the Export-Package header may be configured globally as well.
> On Apr 1, 2016, at 1:17 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
> Hi
>
> On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider
> <chris@die-schneider.net <ma...@die-schneider.net>> wrote:
>> I recently worked on some projects that also need OSGi settings and found an
>> interesting thing.
>> It seems the easiest way to get the exports, imports and other OSGi settings
>> right is not to use central defaults and instead do all settings per project
>> while relying on defaults as much as possible.
>>
>
> Christian is the wording correct? I read this a bit like "do not use
> central defaults" and then "rely on default as much as possible" are
> they not the opposite?
>
> Do you mean do not use central defaults. And if you must then as
> little as possible?
>
>
>
>
>> I use these settings in the parent:
>> https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L199-L223
>>
>> So basically what I do is to only activate the bundle plugin in the parent
>> and set it to not auto export packages. For bnd-maven-plugin this should not
>> be necessary as it is the default.
>> I then delegate the OSGi settings to a bnd.bnd file. This is largely equal
>> to the pom config but a little less verbose.
>>
>> An example can be found at:
>> https://github.com/apache/aries-rsa/tree/master/rsa
>> https://github.com/apache/aries-rsa/blob/master/rsa/bnd.bnd
>>
>> As you see the pom of each project contains no OSGi informations at all and
>> the bnd.bnd files are very small.
>> So I would recommend this approach for camel too.
>>
>
> Ah so instead of having osgi stuff mixed around in parent central pom
> files, and then with some overlays in current pom.xml, you are solely
> using a bnd.bnd file per module.
>
> So that would mean we would need to do a bnd.bnd file per Camel module
> that is an OSGi bundle?
> And how much do you need to configure those bnd.bnd files? Today we
> get the import|export generated.
>
>
>> Christian
>>
>>
>> On 24.03.2016 16:18, Claus Ibsen wrote:
>>>
>>> On Thu, Mar 24, 2016 at 4:10 PM, Quinn Stevenson
>>> <qu...@pronoia-solutions.com> 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 <cl...@gmail.com> 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
>>>>> <qu...@pronoia-solutions.com> 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
>>>>>>> <an...@stefanutti.fr> 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 <cl...@gmail.com> 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 <cl...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> So Camel 2.17 was the last release supporting Java 1.7.
>>>>>>>>> The next Camel 2.18 is requiring Java 1.8.
>>>>>>>>>
>>>>>>>>> Here is some thoughts of mine about this release up for discussion.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> a)
>>>>>>>>> I see the overall goal of Camel 2.18 as a stepping stone towards
>>>>>>>>> Java
>>>>>>>>> 1.8 and Camel 3.0.
>>>>>>>>>
>>>>>>>>> By that I mean the release should be a way of moving our existing
>>>>>>>>> users from Java 1.7 and the current Camel APIs and the likes
>>>>>>>>> gradually
>>>>>>>>> towards Java 1.8 and eventually Camel 3.0.
>>>>>>>>>
>>>>>>>>> In other words we should not get carried away to change/break APIs
>>>>>>>>> and
>>>>>>>>> whatnot just because Java 1.8 lambdas and functions.
>>>>>>>>>
>>>>>>>>> There are too many current users that rely on the current Camel API
>>>>>>>>> and we cannot go around change processor / expression / predicate /
>>>>>>>>> aggregation strategy and other interfaces to be java 8 functional if
>>>>>>>>> that means current code cannot compile. And certainly not adding
>>>>>>>>> Optional<X> as return types all over.
>>>>>>>>>
>>>>>>>>> The following releases (Camel 2.19 or 3.0) can pick up that torch
>>>>>>>>> and
>>>>>>>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>>>>>>>> changes that are Java 8 lambda / functional based. And as well
>>>>>>>>> changes
>>>>>>>>> in the DSL to go with that.
>>>>>>>>>
>>>>>>>>> There are some minor code changes needed to make the source compile
>>>>>>>>> as
>>>>>>>>> source 1.8 to go in this Camel 2.18 let alone.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> b)
>>>>>>>>> Drop components that do not support and run on Java 1.8
>>>>>>>>> And potentially remove some deprecated components
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> c)
>>>>>>>>> Drop karaf 2.x.
>>>>>>>>> And move to karaf 4.x for all our testing.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> d)
>>>>>>>>> Drop Jetty 8.x.
>>>>>>>>>
>>>>>>>>> This also requires to upgrade at least two components that currently
>>>>>>>>> rely on Jetty 8 to use Jetty 9.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> e)
>>>>>>>>> Upgrade to latest Jetty 9.
>>>>>>>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> f)
>>>>>>>>> Drop support for older versions of Spring. We have a number of
>>>>>>>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>>>>>>>> spring 4.0. as its also EOL.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> g)
>>>>>>>>> Potentially move spring-dm out of camel-spring into a
>>>>>>>>> camel-spring-dm
>>>>>>>>> module. So camel-spring can use latest version of Spring safely.
>>>>>>>>> This
>>>>>>>>> also makes it easier to deprecated spring-dm and remove it
>>>>>>>>> eventually.
>>>>>>>>> The Karaf team is working on a sping -> blueprint layer so you can
>>>>>>>>> use
>>>>>>>>> spring xml files but Karaf will "convert" that under the hood to
>>>>>>>>> blueprint and run it as blueprint. When that is ready we no longer
>>>>>>>>> need spring-dm.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> h)
>>>>>>>>> Continue adding components docs in the source, eg src/main/doc
>>>>>>>>> files.
>>>>>>>>> So we eventually have as many/all of them. This is an ongoing
>>>>>>>>> effort,
>>>>>>>>> as we need to do this for the EIPs and the other parts of the docs.
>>>>>>>>>
>>>>>>>>> However I see this as a great step for a new documentation and
>>>>>>>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>>>>>>>> website fresh and modern. And make the documentation easier for end
>>>>>>>>> users to use and view.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> i)
>>>>>>>>> Add camel-hysterix component and integrate camel's circuit breaker
>>>>>>>>> into turbine/hysterix so you can see metrics from camel in the
>>>>>>>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> j)
>>>>>>>>> Split camel-cxf into modules so we can separate WS and RS and also
>>>>>>>>> spring vs blueprint. Today its big ball of dependencies that is a
>>>>>>>>> bit
>>>>>>>>> hard to slice and dice. Specially for MSA style with REST and you
>>>>>>>>> dont
>>>>>>>>> want to add in a bunch of extra not needed JARs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> k)
>>>>>>>>> Continue as usual by adding new components, data formats, fix bugs,
>>>>>>>>> and so on.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> l)
>>>>>>>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>>>>>>>> could try to get this "stepping stone" release done sooner, so it
>>>>>>>>> can
>>>>>>>>> be released during/shortly after summer.
>>>>>>>>>
>>>>>>>>> There is plenty of "first work" that we must do with the java 8
>>>>>>>>> upgrade and dropping older techs etc, that we have our hands full
>>>>>>>>> for
>>>>>>>>> a while.
>>>>>>>>>
>>>>>>>>> Doing a release with these changes allows our end users to migrate
>>>>>>>>> along in a easy way, than a big bang - breaking apis - release would
>>>>>>>>> do. And the latter would be more appropriate to be released as Camel
>>>>>>>>> 3.0.
>>>>>>>>>
>>>>>>>>> Then towards the end of this year, we can see where we are and plan
>>>>>>>>> for a Camel 3.0 with a new website and documentation that such a
>>>>>>>>> release deserve. For example if we release Camel 3.0 in start of
>>>>>>>>> 2017
>>>>>>>>> then its also Camel's 10 year birthday year.
>>>>>>>>>
>>>>>>>>> And doing such a release with a rewamped website with fresh looking
>>>>>>>>> documentation and content, is what helps the project a lot.
>>>>>>>>>
>>>>>>>>> The current website looks the same as it did when it was created:
>>>>>>>>>
>>>>>>>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>>>>>>>
>>>>>>>>> PS: We surely also need a better "what is Camel" story on the front
>>>>>>>>> page. Its still that very first one with all the tech jumble that
>>>>>>>>> was
>>>>>>>>> initially created.
>>>>>>>>>
>>>>>>>>> PPS: I would also love to see a new Camel logo. The current one is a
>>>>>>>>> bit dull and boring.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Claus Ibsen
>>>>>>>>> -----------------
>>>>>>>>> http://davsclaus.com @davsclaus
>>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Claus Ibsen
>>>>>>>> -----------------
>>>>>>>> http://davsclaus.com @davsclaus
>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> http://davsclaus.com @davsclaus
>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>>
>>>
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> I recently worked on some projects that also need OSGi settings and found an
> interesting thing.
> It seems the easiest way to get the exports, imports and other OSGi settings
> right is not to use central defaults and instead do all settings per project
> while relying on defaults as much as possible.
>
Christian is the wording correct? I read this a bit like "do not use
central defaults" and then "rely on default as much as possible" are
they not the opposite?
Do you mean do not use central defaults. And if you must then as
little as possible?
> I use these settings in the parent:
> https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L199-L223
>
> So basically what I do is to only activate the bundle plugin in the parent
> and set it to not auto export packages. For bnd-maven-plugin this should not
> be necessary as it is the default.
> I then delegate the OSGi settings to a bnd.bnd file. This is largely equal
> to the pom config but a little less verbose.
>
> An example can be found at:
> https://github.com/apache/aries-rsa/tree/master/rsa
> https://github.com/apache/aries-rsa/blob/master/rsa/bnd.bnd
>
> As you see the pom of each project contains no OSGi informations at all and
> the bnd.bnd files are very small.
> So I would recommend this approach for camel too.
>
Ah so instead of having osgi stuff mixed around in parent central pom
files, and then with some overlays in current pom.xml, you are solely
using a bnd.bnd file per module.
So that would mean we would need to do a bnd.bnd file per Camel module
that is an OSGi bundle?
And how much do you need to configure those bnd.bnd files? Today we
get the import|export generated.
> Christian
>
>
> On 24.03.2016 16:18, Claus Ibsen wrote:
>>
>> On Thu, Mar 24, 2016 at 4:10 PM, Quinn Stevenson
>> <qu...@pronoia-solutions.com> 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 <cl...@gmail.com> 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
>>>> <qu...@pronoia-solutions.com> 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
>>>>>> <an...@stefanutti.fr> 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 <cl...@gmail.com> 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 <cl...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> So Camel 2.17 was the last release supporting Java 1.7.
>>>>>>>> The next Camel 2.18 is requiring Java 1.8.
>>>>>>>>
>>>>>>>> Here is some thoughts of mine about this release up for discussion.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> a)
>>>>>>>> I see the overall goal of Camel 2.18 as a stepping stone towards
>>>>>>>> Java
>>>>>>>> 1.8 and Camel 3.0.
>>>>>>>>
>>>>>>>> By that I mean the release should be a way of moving our existing
>>>>>>>> users from Java 1.7 and the current Camel APIs and the likes
>>>>>>>> gradually
>>>>>>>> towards Java 1.8 and eventually Camel 3.0.
>>>>>>>>
>>>>>>>> In other words we should not get carried away to change/break APIs
>>>>>>>> and
>>>>>>>> whatnot just because Java 1.8 lambdas and functions.
>>>>>>>>
>>>>>>>> There are too many current users that rely on the current Camel API
>>>>>>>> and we cannot go around change processor / expression / predicate /
>>>>>>>> aggregation strategy and other interfaces to be java 8 functional if
>>>>>>>> that means current code cannot compile. And certainly not adding
>>>>>>>> Optional<X> as return types all over.
>>>>>>>>
>>>>>>>> The following releases (Camel 2.19 or 3.0) can pick up that torch
>>>>>>>> and
>>>>>>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>>>>>>> changes that are Java 8 lambda / functional based. And as well
>>>>>>>> changes
>>>>>>>> in the DSL to go with that.
>>>>>>>>
>>>>>>>> There are some minor code changes needed to make the source compile
>>>>>>>> as
>>>>>>>> source 1.8 to go in this Camel 2.18 let alone.
>>>>>>>>
>>>>>>>>
>>>>>>>> b)
>>>>>>>> Drop components that do not support and run on Java 1.8
>>>>>>>> And potentially remove some deprecated components
>>>>>>>>
>>>>>>>>
>>>>>>>> c)
>>>>>>>> Drop karaf 2.x.
>>>>>>>> And move to karaf 4.x for all our testing.
>>>>>>>>
>>>>>>>>
>>>>>>>> d)
>>>>>>>> Drop Jetty 8.x.
>>>>>>>>
>>>>>>>> This also requires to upgrade at least two components that currently
>>>>>>>> rely on Jetty 8 to use Jetty 9.
>>>>>>>>
>>>>>>>>
>>>>>>>> e)
>>>>>>>> Upgrade to latest Jetty 9.
>>>>>>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>>>>>>
>>>>>>>>
>>>>>>>> f)
>>>>>>>> Drop support for older versions of Spring. We have a number of
>>>>>>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>>>>>>> spring 4.0. as its also EOL.
>>>>>>>>
>>>>>>>>
>>>>>>>> g)
>>>>>>>> Potentially move spring-dm out of camel-spring into a
>>>>>>>> camel-spring-dm
>>>>>>>> module. So camel-spring can use latest version of Spring safely.
>>>>>>>> This
>>>>>>>> also makes it easier to deprecated spring-dm and remove it
>>>>>>>> eventually.
>>>>>>>> The Karaf team is working on a sping -> blueprint layer so you can
>>>>>>>> use
>>>>>>>> spring xml files but Karaf will "convert" that under the hood to
>>>>>>>> blueprint and run it as blueprint. When that is ready we no longer
>>>>>>>> need spring-dm.
>>>>>>>>
>>>>>>>>
>>>>>>>> h)
>>>>>>>> Continue adding components docs in the source, eg src/main/doc
>>>>>>>> files.
>>>>>>>> So we eventually have as many/all of them. This is an ongoing
>>>>>>>> effort,
>>>>>>>> as we need to do this for the EIPs and the other parts of the docs.
>>>>>>>>
>>>>>>>> However I see this as a great step for a new documentation and
>>>>>>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>>>>>>> website fresh and modern. And make the documentation easier for end
>>>>>>>> users to use and view.
>>>>>>>>
>>>>>>>>
>>>>>>>> i)
>>>>>>>> Add camel-hysterix component and integrate camel's circuit breaker
>>>>>>>> into turbine/hysterix so you can see metrics from camel in the
>>>>>>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>>>>>>
>>>>>>>>
>>>>>>>> j)
>>>>>>>> Split camel-cxf into modules so we can separate WS and RS and also
>>>>>>>> spring vs blueprint. Today its big ball of dependencies that is a
>>>>>>>> bit
>>>>>>>> hard to slice and dice. Specially for MSA style with REST and you
>>>>>>>> dont
>>>>>>>> want to add in a bunch of extra not needed JARs.
>>>>>>>>
>>>>>>>>
>>>>>>>> k)
>>>>>>>> Continue as usual by adding new components, data formats, fix bugs,
>>>>>>>> and so on.
>>>>>>>>
>>>>>>>>
>>>>>>>> l)
>>>>>>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>>>>>>> could try to get this "stepping stone" release done sooner, so it
>>>>>>>> can
>>>>>>>> be released during/shortly after summer.
>>>>>>>>
>>>>>>>> There is plenty of "first work" that we must do with the java 8
>>>>>>>> upgrade and dropping older techs etc, that we have our hands full
>>>>>>>> for
>>>>>>>> a while.
>>>>>>>>
>>>>>>>> Doing a release with these changes allows our end users to migrate
>>>>>>>> along in a easy way, than a big bang - breaking apis - release would
>>>>>>>> do. And the latter would be more appropriate to be released as Camel
>>>>>>>> 3.0.
>>>>>>>>
>>>>>>>> Then towards the end of this year, we can see where we are and plan
>>>>>>>> for a Camel 3.0 with a new website and documentation that such a
>>>>>>>> release deserve. For example if we release Camel 3.0 in start of
>>>>>>>> 2017
>>>>>>>> then its also Camel's 10 year birthday year.
>>>>>>>>
>>>>>>>> And doing such a release with a rewamped website with fresh looking
>>>>>>>> documentation and content, is what helps the project a lot.
>>>>>>>>
>>>>>>>> The current website looks the same as it did when it was created:
>>>>>>>>
>>>>>>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>>>>>>
>>>>>>>> PS: We surely also need a better "what is Camel" story on the front
>>>>>>>> page. Its still that very first one with all the tech jumble that
>>>>>>>> was
>>>>>>>> initially created.
>>>>>>>>
>>>>>>>> PPS: I would also love to see a new Camel logo. The current one is a
>>>>>>>> bit dull and boring.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Claus Ibsen
>>>>>>>> -----------------
>>>>>>>> http://davsclaus.com @davsclaus
>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> -----------------
>>>>>>> http://davsclaus.com @davsclaus
>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
I recently worked on some projects that also need OSGi settings and
found an interesting thing.
It seems the easiest way to get the exports, imports and other OSGi
settings right is not to use central defaults and instead do all
settings per project while relying on defaults as much as possible.
I use these settings in the parent:
https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L199-L223
So basically what I do is to only activate the bundle plugin in the
parent and set it to not auto export packages. For bnd-maven-plugin this
should not be necessary as it is the default.
I then delegate the OSGi settings to a bnd.bnd file. This is largely
equal to the pom config but a little less verbose.
An example can be found at:
https://github.com/apache/aries-rsa/tree/master/rsa
https://github.com/apache/aries-rsa/blob/master/rsa/bnd.bnd
As you see the pom of each project contains no OSGi informations at all
and the bnd.bnd files are very small.
So I would recommend this approach for camel too.
Christian
On 24.03.2016 16:18, Claus Ibsen wrote:
> On Thu, Mar 24, 2016 at 4:10 PM, Quinn Stevenson
> <qu...@pronoia-solutions.com> 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 <cl...@gmail.com> 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
>>> <qu...@pronoia-solutions.com> 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 <an...@stefanutti.fr> 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 <cl...@gmail.com> 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 <cl...@gmail.com> wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> So Camel 2.17 was the last release supporting Java 1.7.
>>>>>>> The next Camel 2.18 is requiring Java 1.8.
>>>>>>>
>>>>>>> Here is some thoughts of mine about this release up for discussion.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> a)
>>>>>>> I see the overall goal of Camel 2.18 as a stepping stone towards Java
>>>>>>> 1.8 and Camel 3.0.
>>>>>>>
>>>>>>> By that I mean the release should be a way of moving our existing
>>>>>>> users from Java 1.7 and the current Camel APIs and the likes gradually
>>>>>>> towards Java 1.8 and eventually Camel 3.0.
>>>>>>>
>>>>>>> In other words we should not get carried away to change/break APIs and
>>>>>>> whatnot just because Java 1.8 lambdas and functions.
>>>>>>>
>>>>>>> There are too many current users that rely on the current Camel API
>>>>>>> and we cannot go around change processor / expression / predicate /
>>>>>>> aggregation strategy and other interfaces to be java 8 functional if
>>>>>>> that means current code cannot compile. And certainly not adding
>>>>>>> Optional<X> as return types all over.
>>>>>>>
>>>>>>> The following releases (Camel 2.19 or 3.0) can pick up that torch and
>>>>>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>>>>>> changes that are Java 8 lambda / functional based. And as well changes
>>>>>>> in the DSL to go with that.
>>>>>>>
>>>>>>> There are some minor code changes needed to make the source compile as
>>>>>>> source 1.8 to go in this Camel 2.18 let alone.
>>>>>>>
>>>>>>>
>>>>>>> b)
>>>>>>> Drop components that do not support and run on Java 1.8
>>>>>>> And potentially remove some deprecated components
>>>>>>>
>>>>>>>
>>>>>>> c)
>>>>>>> Drop karaf 2.x.
>>>>>>> And move to karaf 4.x for all our testing.
>>>>>>>
>>>>>>>
>>>>>>> d)
>>>>>>> Drop Jetty 8.x.
>>>>>>>
>>>>>>> This also requires to upgrade at least two components that currently
>>>>>>> rely on Jetty 8 to use Jetty 9.
>>>>>>>
>>>>>>>
>>>>>>> e)
>>>>>>> Upgrade to latest Jetty 9.
>>>>>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>>>>>
>>>>>>>
>>>>>>> f)
>>>>>>> Drop support for older versions of Spring. We have a number of
>>>>>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>>>>>> spring 4.0. as its also EOL.
>>>>>>>
>>>>>>>
>>>>>>> g)
>>>>>>> Potentially move spring-dm out of camel-spring into a camel-spring-dm
>>>>>>> module. So camel-spring can use latest version of Spring safely. This
>>>>>>> also makes it easier to deprecated spring-dm and remove it eventually.
>>>>>>> The Karaf team is working on a sping -> blueprint layer so you can use
>>>>>>> spring xml files but Karaf will "convert" that under the hood to
>>>>>>> blueprint and run it as blueprint. When that is ready we no longer
>>>>>>> need spring-dm.
>>>>>>>
>>>>>>>
>>>>>>> h)
>>>>>>> Continue adding components docs in the source, eg src/main/doc files.
>>>>>>> So we eventually have as many/all of them. This is an ongoing effort,
>>>>>>> as we need to do this for the EIPs and the other parts of the docs.
>>>>>>>
>>>>>>> However I see this as a great step for a new documentation and
>>>>>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>>>>>> website fresh and modern. And make the documentation easier for end
>>>>>>> users to use and view.
>>>>>>>
>>>>>>>
>>>>>>> i)
>>>>>>> Add camel-hysterix component and integrate camel's circuit breaker
>>>>>>> into turbine/hysterix so you can see metrics from camel in the
>>>>>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>>>>>
>>>>>>>
>>>>>>> j)
>>>>>>> Split camel-cxf into modules so we can separate WS and RS and also
>>>>>>> spring vs blueprint. Today its big ball of dependencies that is a bit
>>>>>>> hard to slice and dice. Specially for MSA style with REST and you dont
>>>>>>> want to add in a bunch of extra not needed JARs.
>>>>>>>
>>>>>>>
>>>>>>> k)
>>>>>>> Continue as usual by adding new components, data formats, fix bugs, and so on.
>>>>>>>
>>>>>>>
>>>>>>> l)
>>>>>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>>>>>> could try to get this "stepping stone" release done sooner, so it can
>>>>>>> be released during/shortly after summer.
>>>>>>>
>>>>>>> There is plenty of "first work" that we must do with the java 8
>>>>>>> upgrade and dropping older techs etc, that we have our hands full for
>>>>>>> a while.
>>>>>>>
>>>>>>> Doing a release with these changes allows our end users to migrate
>>>>>>> along in a easy way, than a big bang - breaking apis - release would
>>>>>>> do. And the latter would be more appropriate to be released as Camel
>>>>>>> 3.0.
>>>>>>>
>>>>>>> Then towards the end of this year, we can see where we are and plan
>>>>>>> for a Camel 3.0 with a new website and documentation that such a
>>>>>>> release deserve. For example if we release Camel 3.0 in start of 2017
>>>>>>> then its also Camel's 10 year birthday year.
>>>>>>>
>>>>>>> And doing such a release with a rewamped website with fresh looking
>>>>>>> documentation and content, is what helps the project a lot.
>>>>>>>
>>>>>>> The current website looks the same as it did when it was created:
>>>>>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>>>>>
>>>>>>> PS: We surely also need a better "what is Camel" story on the front
>>>>>>> page. Its still that very first one with all the tech jumble that was
>>>>>>> initially created.
>>>>>>>
>>>>>>> PPS: I would also love to see a new Camel logo. The current one is a
>>>>>>> bit dull and boring.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> -----------------
>>>>>>> http://davsclaus.com @davsclaus
>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> -----------------
>>>>>> http://davsclaus.com @davsclaus
>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Mar 24, 2016 at 4:10 PM, Quinn Stevenson
<qu...@pronoia-solutions.com> 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 <cl...@gmail.com> 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
>> <qu...@pronoia-solutions.com> 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 <an...@stefanutti.fr> 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 <cl...@gmail.com> 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 <cl...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <cl...@gmail.com> 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
> <qu...@pronoia-solutions.com> 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 <an...@stefanutti.fr> 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 <cl...@gmail.com> 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 <cl...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
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
<qu...@pronoia-solutions.com> 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 <an...@stefanutti.fr> 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 <cl...@gmail.com> 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 <cl...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <an...@stefanutti.fr> 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 <cl...@gmail.com> 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 <cl...@gmail.com> 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
>
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Antonin Stefanutti <an...@stefanutti.fr>.
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 <cl...@gmail.com> 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 <cl...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
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 <cl...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Raul Kripalani <ra...@apache.org>.
On Thu, Mar 24, 2016 at 8:55 PM, Claus Ibsen <cl...@gmail.com> 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>
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Matt Pavlovich <ma...@gmail.com>.
On 3/24/16 3:55 PM, Claus Ibsen wrote:
> On Thu, Mar 24, 2016 at 6:24 PM, Krzysztof Sobkowiak
> <kr...@gmail.com> wrote:
>> Hi
>>
>> I'm not sure how the Camel Core actually looks like (especially the quality and the ability to refactor or make more
>> complicated changes) but I had occasion to talk with some people using Camel and trying to fix some issues (and
>> even saw some discussion in net about the state of Core) who think, the Core became very complicated over the
>> years and it would be very difficult to make big changes in it. I think, it's normal that the software which is developed
>> a long time can have code which is no more used or should be refactored.
>>
>> I think, the way to Camel 3 should also include the renovation of the Core (if really necessary) or even rewriting and
>> making it more asynchronous, e.g. using rx.java (the later can be eventually part of Camel 4 roadmap if too dangerous
>> for Camel 3).
>>
> No this should not be the goal of Camel 3 IMHO. This is too disruptive
> and would take too much effort and time away from other tasks. The
> most important is to have a modern website, documentation and getting
> started guides, examples and so on. So people can get onboard Camel.
+1
> The renovation of the core is to cleanup all the deprecated stuff and
> we will take a 2nd look after the 2.17 release to identify more stuff
> to mark for deprecation in 2.18 and removal for 3.0.
+1
> Yes for Camel 4 a new reactive/modern core could be on the agenda. And
> then the time gap between Camel 3 and 4 do not have to be 6 years. For
> example Spring is not reactive yet, but they are going there in Spring
> 5.x [1]. So when reactive becomes more main stream (with help from
> Spring) and useable for the average developers then its likely also
> interest for Camel users. Remember Camel users are no the "netflix
> developers". Its use by every day developers. And we have a huge
> community which we should not throw under the bus with risky moves.
Agreed. Our users are Enterprise developers that deploying software for
5-30 years. Having Camel a Camel 3.x with these goals provides a ton of
value to a user base that is large and mostly silent in these conversations.
> People who want to look at reactive frameworks today can take a look
> at vert.x, akka (problem a bit bad due Scala, but I think the company
> behind them are moving to Java). For vert.x then their next release
> will have a vertx-camel component out of the box.
>
> There has been a camel-rx component for several years now, but nobody
> has shown interest in it. Nor is people screaming in this community
> about reactive libraries. In fact people rely on Camel being "not in
> the forefront"
>
>
> [1] - https://spring.io/blog/2015/12/03/spring-framework-5-0-roadmap-update
>
>
>> My 2 cents, but I think, we have here many people who are Camel experts and can say more, whether it makes sense.
>>
>> Kindly regards
>> Krzysztof
>>
>> On 23.03.2016 11:07, Claus Ibsen wrote:
>>> Hi
>>>
>>> So Camel 2.17 was the last release supporting Java 1.7.
>>> The next Camel 2.18 is requiring Java 1.8.
>>>
>>> Here is some thoughts of mine about this release up for discussion.
>>>
>>>
>>>
>>> a)
>>> I see the overall goal of Camel 2.18 as a stepping stone towards Java
>>> 1.8 and Camel 3.0.
>>>
>>> By that I mean the release should be a way of moving our existing
>>> users from Java 1.7 and the current Camel APIs and the likes gradually
>>> towards Java 1.8 and eventually Camel 3.0.
>>>
>>> In other words we should not get carried away to change/break APIs and
>>> whatnot just because Java 1.8 lambdas and functions.
>>>
>>> There are too many current users that rely on the current Camel API
>>> and we cannot go around change processor / expression / predicate /
>>> aggregation strategy and other interfaces to be java 8 functional if
>>> that means current code cannot compile. And certainly not adding
>>> Optional<X> as return types all over.
>>>
>>> The following releases (Camel 2.19 or 3.0) can pick up that torch and
>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API
>>> changes that are Java 8 lambda / functional based. And as well changes
>>> in the DSL to go with that.
>>>
>>> There are some minor code changes needed to make the source compile as
>>> source 1.8 to go in this Camel 2.18 let alone.
>>>
>>>
>>> b)
>>> Drop components that do not support and run on Java 1.8
>>> And potentially remove some deprecated components
>>>
>>>
>>> c)
>>> Drop karaf 2.x.
>>> And move to karaf 4.x for all our testing.
>>>
>>>
>>> d)
>>> Drop Jetty 8.x.
>>>
>>> This also requires to upgrade at least two components that currently
>>> rely on Jetty 8 to use Jetty 9.
>>>
>>>
>>> e)
>>> Upgrade to latest Jetty 9.
>>> Jetty 9.3 (or is it 9.4) requires Java 1.8
>>>
>>>
>>> f)
>>> Drop support for older versions of Spring. We have a number of
>>> camel-test-spring3 etc modules that can be dropped. And maybe even
>>> spring 4.0. as its also EOL.
>>>
>>>
>>> g)
>>> Potentially move spring-dm out of camel-spring into a camel-spring-dm
>>> module. So camel-spring can use latest version of Spring safely. This
>>> also makes it easier to deprecated spring-dm and remove it eventually.
>>> The Karaf team is working on a sping -> blueprint layer so you can use
>>> spring xml files but Karaf will "convert" that under the hood to
>>> blueprint and run it as blueprint. When that is ready we no longer
>>> need spring-dm.
>>>
>>>
>>> h)
>>> Continue adding components docs in the source, eg src/main/doc files.
>>> So we eventually have as many/all of them. This is an ongoing effort,
>>> as we need to do this for the EIPs and the other parts of the docs.
>>>
>>> However I see this as a great step for a new documentation and
>>> website, that IMHO is a big goal for Camel 3.0. To make the project
>>> website fresh and modern. And make the documentation easier for end
>>> users to use and view.
>>>
>>>
>>> i)
>>> Add camel-hysterix component and integrate camel's circuit breaker
>>> into turbine/hysterix so you can see metrics from camel in the
>>> dashboard. Eg to integrate with the popular Netflix OSS stack.
>>>
>>>
>>> j)
>>> Split camel-cxf into modules so we can separate WS and RS and also
>>> spring vs blueprint. Today its big ball of dependencies that is a bit
>>> hard to slice and dice. Specially for MSA style with REST and you dont
>>> want to add in a bunch of extra not needed JARs.
>>>
>>>
>>> k)
>>> Continue as usual by adding new components, data formats, fix bugs, and so on.
>>>
>>>
>>> l)
>>> Timeline. This release do not need to have 6-8 months timeframe. We
>>> could try to get this "stepping stone" release done sooner, so it can
>>> be released during/shortly after summer.
>>>
>>> There is plenty of "first work" that we must do with the java 8
>>> upgrade and dropping older techs etc, that we have our hands full for
>>> a while.
>>>
>>> Doing a release with these changes allows our end users to migrate
>>> along in a easy way, than a big bang - breaking apis - release would
>>> do. And the latter would be more appropriate to be released as Camel
>>> 3.0.
>>>
>>> Then towards the end of this year, we can see where we are and plan
>>> for a Camel 3.0 with a new website and documentation that such a
>>> release deserve. For example if we release Camel 3.0 in start of 2017
>>> then its also Camel's 10 year birthday year.
>>>
>>> And doing such a release with a rewamped website with fresh looking
>>> documentation and content, is what helps the project a lot.
>>>
>>> The current website looks the same as it did when it was created:
>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>
>>> PS: We surely also need a better "what is Camel" story on the front
>>> page. Its still that very first one with all the tech jumble that was
>>> initially created.
>>>
>>> PPS: I would also love to see a new Camel logo. The current one is a
>>> bit dull and boring.
>>>
>>>
>>>
>>>
>> --
>> Krzysztof Sobkowiak (@ksobkowiak)
>>
>> JEE & OSS Architect, Integration Architect
>> Apache Software Foundation Member (http://apache.org/)
>> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
>> Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
>
>
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Mar 24, 2016 at 6:24 PM, Krzysztof Sobkowiak
<kr...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Matt Pavlovich <ma...@gmail.com>.
Johan-
I'm a big fan of long winded statements as well, but not following this
one =)
Are you suggesting the current core architecture is problematic or that
a conversion to something like reactive would result in "strange" bugs?
Thanks,
Matt
On 4/4/16 10:52 AM, Johan Edstrom wrote:
> I think the core should focus on speed, consistency, reliability
> and last extensibility; Camel has a nice traction but we don’t
> want to see “strange” bugs from new features if that makes
> sense as a long windy sentence…..
>
>
>
>> On Apr 4, 2016, at 9:36 AM, Matt Pavlovich <ma...@gmail.com> wrote:
>>
>>
>>
>> On 3/24/16 3:27 PM, Raul Kripalani wrote:
>>> On Thu, Mar 24, 2016 at 5:24 PM, Krzysztof Sobkowiak <
>>> krzys.sobkowiak@gmail.com> wrote:
>>>
>>>> I think, the way to Camel 3 should also include the renovation of the Core
>>>> (if really necessary) or even rewriting and
>>>> making it more asynchronous, e.g. using rx.java (the later can be
>>>> eventually part of Camel 4 roadmap if too dangerous
>>>> for Camel 3).
>>>>
>>> This also relates to the concurrency model. Camel revolves around the idea
>>> that more threads == more performance. Our processing actually
>>> hijacks/piggy-backs the threads of the 3rd party library of the component
>>> (Netty, Jetty, Spring JMS, etc. threads), and this is not good. One just
>>> needs to look around: reactive programming, coroutines, event loops,
>>> generators, goroutines (in Go), etc. to realise we're kinda obsolete by now.
>> "Obsolete" by what standard?
>>> The async routing engine was a step in the right direction, but most
>>> components don't even support it.
>>>
>>> Now that we know the reactive programming model is here to stay and it
>>> wasn't a fad, I feel we should definitely go in that direction. We should
>>> look at Akka, RxJava and the Reactive Streams [3] spec.
>> I expect there will be long term valuable pieces pulled from reactive programming, just as there are from virtually every new "paradigm" that pops up every few years-- but there will also be a balance of "doesn't meet the hype". Anyone remember AOP (Btw-- which now has 3-4 sub-derivatives)? I suggest letting the dust settle to see what the benefits-tradeoffs matrix looks like before committing to overhauling Camel core.
>>
>> -Matt
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Johan Edstrom <se...@gmail.com>.
I think the core should focus on speed, consistency, reliability
and last extensibility; Camel has a nice traction but we don’t
want to see “strange” bugs from new features if that makes
sense as a long windy sentence…..
> On Apr 4, 2016, at 9:36 AM, Matt Pavlovich <ma...@gmail.com> wrote:
>
>
>
> On 3/24/16 3:27 PM, Raul Kripalani wrote:
>> On Thu, Mar 24, 2016 at 5:24 PM, Krzysztof Sobkowiak <
>> krzys.sobkowiak@gmail.com> wrote:
>>
>>> I think, the way to Camel 3 should also include the renovation of the Core
>>> (if really necessary) or even rewriting and
>>> making it more asynchronous, e.g. using rx.java (the later can be
>>> eventually part of Camel 4 roadmap if too dangerous
>>> for Camel 3).
>>>
>> This also relates to the concurrency model. Camel revolves around the idea
>> that more threads == more performance. Our processing actually
>> hijacks/piggy-backs the threads of the 3rd party library of the component
>> (Netty, Jetty, Spring JMS, etc. threads), and this is not good. One just
>> needs to look around: reactive programming, coroutines, event loops,
>> generators, goroutines (in Go), etc. to realise we're kinda obsolete by now.
> "Obsolete" by what standard?
>> The async routing engine was a step in the right direction, but most
>> components don't even support it.
>>
>> Now that we know the reactive programming model is here to stay and it
>> wasn't a fad, I feel we should definitely go in that direction. We should
>> look at Akka, RxJava and the Reactive Streams [3] spec.
> I expect there will be long term valuable pieces pulled from reactive programming, just as there are from virtually every new "paradigm" that pops up every few years-- but there will also be a balance of "doesn't meet the hype". Anyone remember AOP (Btw-- which now has 3-4 sub-derivatives)? I suggest letting the dust settle to see what the benefits-tradeoffs matrix looks like before committing to overhauling Camel core.
>
> -Matt
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Matt Pavlovich <ma...@gmail.com>.
On 3/24/16 3:27 PM, Raul Kripalani wrote:
> On Thu, Mar 24, 2016 at 5:24 PM, Krzysztof Sobkowiak <
> krzys.sobkowiak@gmail.com> wrote:
>
>> I think, the way to Camel 3 should also include the renovation of the Core
>> (if really necessary) or even rewriting and
>> making it more asynchronous, e.g. using rx.java (the later can be
>> eventually part of Camel 4 roadmap if too dangerous
>> for Camel 3).
>>
> This also relates to the concurrency model. Camel revolves around the idea
> that more threads == more performance. Our processing actually
> hijacks/piggy-backs the threads of the 3rd party library of the component
> (Netty, Jetty, Spring JMS, etc. threads), and this is not good. One just
> needs to look around: reactive programming, coroutines, event loops,
> generators, goroutines (in Go), etc. to realise we're kinda obsolete by now.
"Obsolete" by what standard?
> The async routing engine was a step in the right direction, but most
> components don't even support it.
>
> Now that we know the reactive programming model is here to stay and it
> wasn't a fad, I feel we should definitely go in that direction. We should
> look at Akka, RxJava and the Reactive Streams [3] spec.
I expect there will be long term valuable pieces pulled from reactive
programming, just as there are from virtually every new "paradigm" that
pops up every few years-- but there will also be a balance of "doesn't
meet the hype". Anyone remember AOP (Btw-- which now has 3-4
sub-derivatives)? I suggest letting the dust settle to see what the
benefits-tradeoffs matrix looks like before committing to overhauling
Camel core.
-Matt
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Raul Kripalani <ra...@apache.org>.
On Thu, Mar 24, 2016 at 5:24 PM, Krzysztof Sobkowiak <
krzys.sobkowiak@gmail.com> 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>
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
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/)
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Antoine Toulme <an...@toulme.name>.
> On Mar 25, 2016, at 10:42 PM, Claus Ibsen <cl...@gmail.com> wrote:
>
> Hi Antoine
>
> Yay sounds good. What do you fancy working with?
>
> We got stuff around OSGi such as
>
> - upgrading the tests to be karaf 4.x based
> - drop karaf 2.x
> - upgrade to OSGi 5.0
Looks like Raul is on top of it. I have some OSGi experience.
>
> Some easier ones would be in the platforms/karaf/features to make
> karaf 4 the default being used in the validation, currently its 2.x.
> And likewise in the tests/camel-itest-karaf.
Easy enough. Will take a look.
>
> For non OSGi stuff then one of the most hard ones is to migrate two
> components to Jetty 9. I think its camel-cometd and camel-websocket.
I would do those first. I have some experience dealing with Jetty.
>
> There is also an easier one to upgrade jetty 9.2 -> 9.3.
>
> And then there is also the component docs to create adoc files. Andrea
> knows how to do that, so he can tell the procedure. There is a way you
> can export from wiki and then manually need to do some adjustments.
I can at least do dns and jackson-xml.
>
> Then there is the splitup of camel-cxf into smaller components to
> separate it from ws/rs and spring/blueprint etc.
>
> And there is also Raul's branch with the change in the build system
> for lambda compilation that affects all OSGi. So it need rigorous OSGi
> testing before it can be merged. See other email in this @dev.
>
> And there is JIRA with the 2.18 tickets
> https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.18.0%20AND%20project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20DESC
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Mar 25, 2016 at 6:47 PM, Antoine Toulme <an...@toulme.name> wrote:
>> I’d like to help for this release. Looks like you got a good laundry list already. Where can I help best in that list?
>>
>>
>>> On Mar 23, 2016, at 3:07 AM, Claus Ibsen <cl...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
Hi Antoine
Yay sounds good. What do you fancy working with?
We got stuff around OSGi such as
- upgrading the tests to be karaf 4.x based
- drop karaf 2.x
- upgrade to OSGi 5.0
Some easier ones would be in the platforms/karaf/features to make
karaf 4 the default being used in the validation, currently its 2.x.
And likewise in the tests/camel-itest-karaf.
For non OSGi stuff then one of the most hard ones is to migrate two
components to Jetty 9. I think its camel-cometd and camel-websocket.
There is also an easier one to upgrade jetty 9.2 -> 9.3.
And then there is also the component docs to create adoc files. Andrea
knows how to do that, so he can tell the procedure. There is a way you
can export from wiki and then manually need to do some adjustments.
Then there is the splitup of camel-cxf into smaller components to
separate it from ws/rs and spring/blueprint etc.
And there is also Raul's branch with the change in the build system
for lambda compilation that affects all OSGi. So it need rigorous OSGi
testing before it can be merged. See other email in this @dev.
And there is JIRA with the 2.18 tickets
https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.18.0%20AND%20project%20%3D%20CAMEL%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20DESC
On Fri, Mar 25, 2016 at 6:47 PM, Antoine Toulme <an...@toulme.name> wrote:
> I’d like to help for this release. Looks like you got a good laundry list already. Where can I help best in that list?
>
>
>> On Mar 23, 2016, at 3:07 AM, Claus Ibsen <cl...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Antoine Toulme <an...@toulme.name>.
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 <cl...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Matt Pavlovich <ma...@gmail.com>.
Jakub-
Sign me up to help with this.
-Matt
On 3/23/16 9:22 AM, jkorab wrote:
> Claus Ibsen-2 wrote
>> PS: We surely also need a better "what is Camel" story on the front
>> page. Its still that very first one with all the tech jumble that was
>> initially created.
> I would be happy to write something up around this. I have some experience
> in explaining Camel to people :)
>
> Jakub
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Thoughts-on-Apache-Camel-2-18-and-towards-3-0-tp5779549p5779565.html
> Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Mar 23, 2016 at 3:22 PM, jkorab <ja...@gmail.com> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by jkorab <ja...@gmail.com>.
Claus Ibsen-2 wrote
> PS: We surely also need a better "what is Camel" story on the front
> page. Its still that very first one with all the tech jumble that was
> initially created.
I would be happy to write something up around this. I have some experience
in explaining Camel to people :)
Jakub
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Thoughts-on-Apache-Camel-2-18-and-towards-3-0-tp5779549p5779565.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Just an update on some of these tasks lined
On Wed, Mar 23, 2016 at 11:07 AM, Claus Ibsen <cl...@gmail.com> 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
>
Not started yet.
>
> c)
> Drop karaf 2.x.
> And move to karaf 4.x for all our testing.
>
The missing part is the tests/camel-itest-osgi which is in a sad state
already. The tests dont run either well today. I wonder if we should
zap it, and recreate a new itest that are up to date. We should then
reuse the work on the camel-test-karaf module that is in the works.
>
> d)
> Drop Jetty 8.x.
>
> This also requires to upgrade at least two components that currently
> rely on Jetty 8 to use Jetty 9.
>
Not started yet
>
> e)
> Upgrade to latest Jetty 9.
> Jetty 9.3 (or is it 9.4) requires Java 1.8
>
Not started yet
>
> 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.
>
Done
>
> 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.
>
Done
>
> 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.
>
Component added. The metrics is still pending.
>
> 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.
>
Not started yet.
>
> 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
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
The migration of the docs is already started with the components. We
are migrating them one by one which takes a rather long time to get
all done, but we do have a good start already.
Thee is docs in the src/doc folder of the components that has been
migrated, such as
https://github.com/apache/camel/blob/master/components/camel-ahc/src/main/docs/ahc.adoc
And a start of a website that put together all that docs at
https://github.com/apache/camel/tree/master/docs/user-manual/en
The latter is just very rough and certainly not set in stone.
The first goal is to get all the component docs migrated. Where it
grabs parts of the docs from the source code and auto maintain in the
.adoc files. So we ensure all the options are always 100% up to date.
We can then do the same for the EIPs as we can do for the docs. And as
well for data formats and languages. So all of them are always up to
date.
The actual look and feel of the website is not started yet. And yes I
do think the Apache Karaf team did a good job of a website make over,
at least on the front page. When you dive down then the docs is the
old style.
On Mon, Apr 4, 2016 at 6:57 PM, Matt Pavlovich <ma...@gmail.com> wrote:
>
>
> On 4/4/16 11:12 AM, Raul Kripalani wrote:
>>
>> On Mon, Apr 4, 2016 at 4:44 PM, Matt Pavlovich <ma...@gmail.com> wrote:
>>
>>> The current website looks the same as it did when it was created:
>>>>
>>>>
>>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>>
>>> I thought the Karaf guys did a nice job on the website re-work. Is there
>>> a
>>> new base framework for all Apache projects, or are we at ground zero on
>>> this?
>>
>>
>> I dig the Karaf redesign - clean, modern and simple. I'd love to aim for
>> something similar in Camel.
>>
>> What do we do about our content editing system? My proposal is to move
>> away
>> from Confluence and adopt Markdown, AsciiDoc, or the like.
>>
>> Pros:
>>
>> 1. Docs can be versioned alongside code
>> 2. The HTML is purer and with less artifacts => accurate styling =>
>> cleaner
>> visuals.
>> 3. A breeze to edit, fix typos, add release notes, etc.
>>
>> Cons:
>>
>> 1. Large migration effort.
>
>
> I agree, a markdown-based CMS would be handy. Do we know what Karaf is
> using?
>
> Re Cons #1: I think the docs need a massive overhaul anyway. Probably a good
> time to just do it.
>
> The component config should be separated by version and not a hodge-podge of
> carve-outs like we have today.
>
> Rough pass at a TOC:
> (Suggest short and sweet)
> Index
> Documentation
> Download
> Support
>
> Then the sub-sections fall under the top level categories.
>
> Documentation
> + Core
> + Components
> + Data Formats
> + etc..
>
> Download
> + Grab the bits
> + Grab the source
> + Links to svn / git etc
>
> Contributor Documentation
> + Camel API
> + etc..
>
> Support
> + Community ( IRC, mailing lists, LinkedIn Group, etc)
> + Commercial
>
>
>
>>
>> Cheers,
>>
>> *Raúl Kripalani*
>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
>> Messaging Engineer
>> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
>> Blog: raul.io
>> <http://raul.io/?utm_source=email&utm_medium=email&utm_campaign=apache> |
>> twitter: @raulvk <https://twitter.com/raulvk>
>>
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Matt Pavlovich <ma...@gmail.com>.
On 4/4/16 11:12 AM, Raul Kripalani wrote:
> On Mon, Apr 4, 2016 at 4:44 PM, Matt Pavlovich <ma...@gmail.com> wrote:
>
>> The current website looks the same as it did when it was created:
>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>>
>> I thought the Karaf guys did a nice job on the website re-work. Is there a
>> new base framework for all Apache projects, or are we at ground zero on
>> this?
>
> I dig the Karaf redesign - clean, modern and simple. I'd love to aim for
> something similar in Camel.
>
> What do we do about our content editing system? My proposal is to move away
> from Confluence and adopt Markdown, AsciiDoc, or the like.
>
> Pros:
>
> 1. Docs can be versioned alongside code
> 2. The HTML is purer and with less artifacts => accurate styling => cleaner
> visuals.
> 3. A breeze to edit, fix typos, add release notes, etc.
>
> Cons:
>
> 1. Large migration effort.
I agree, a markdown-based CMS would be handy. Do we know what Karaf is
using?
Re Cons #1: I think the docs need a massive overhaul anyway. Probably a
good time to just do it.
The component config should be separated by version and not a
hodge-podge of carve-outs like we have today.
Rough pass at a TOC:
(Suggest short and sweet)
Index
Documentation
Download
Support
Then the sub-sections fall under the top level categories.
Documentation
+ Core
+ Components
+ Data Formats
+ etc..
Download
+ Grab the bits
+ Grab the source
+ Links to svn / git etc
Contributor Documentation
+ Camel API
+ etc..
Support
+ Community ( IRC, mailing lists, LinkedIn Group, etc)
+ Commercial
>
> Cheers,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> Blog: raul.io
> <http://raul.io/?utm_source=email&utm_medium=email&utm_campaign=apache> |
> twitter: @raulvk <https://twitter.com/raulvk>
>
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Raul Kripalani <ra...@apache.org>.
On Mon, Apr 4, 2016 at 4:44 PM, Matt Pavlovich <ma...@gmail.com> wrote:
> The current website looks the same as it did when it was created:
>>
>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
>>
> I thought the Karaf guys did a nice job on the website re-work. Is there a
> new base framework for all Apache projects, or are we at ground zero on
> this?
I dig the Karaf redesign - clean, modern and simple. I'd love to aim for
something similar in Camel.
What do we do about our content editing system? My proposal is to move away
from Confluence and adopt Markdown, AsciiDoc, or the like.
Pros:
1. Docs can be versioned alongside code
2. The HTML is purer and with less artifacts => accurate styling => cleaner
visuals.
3. A breeze to edit, fix typos, add release notes, etc.
Cons:
1. Large migration effort.
Cheers,
*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
Blog: raul.io
<http://raul.io/?utm_source=email&utm_medium=email&utm_campaign=apache> |
twitter: @raulvk <https://twitter.com/raulvk>
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Matt Pavlovich <ma...@gmail.com>.
On 3/23/16 5:07 AM, Claus Ibsen wrote:
> j)
> Split camel-cxf into modules so we can separate WS and RS and also
> spring vs blueprint. Today its big ball of dependencies that is a bit
> hard to slice and dice. Specially for MSA style with REST and you dont
> want to add in a bunch of extra not needed JARs.
+1
> l)
> Timeline. This release do not need to have 6-8 months timeframe. We
> could try to get this "stepping stone" release done sooner, so it can
> be released during/shortly after summer.
I think this is a great idea. OSS projects can get bogged down with
ambitious "let's fix everything" goals.
The goals laid out here would setup a great foundation for 3.x to have a
nice run and plenty of room to add sugar.
> And doing such a release with a rewamped website with fresh looking
> documentation and content, is what helps the project a lot.
>
> The current website looks the same as it did when it was created:
> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/
I thought the Karaf guys did a nice job on the website re-work. Is there
a new base framework for all Apache projects, or are we at ground zero
on this?
> PS: We surely also need a better "what is Camel" story on the front
> page. Its still that very first one with all the tech jumble that was
> initially created.
I'm up for helping-- will ping jkorab to coordinate.
> PPS: I would also love to see a new Camel logo. The current one is a
> bit dull and boring.
+1
-Matt
Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Just though I wanted to do a status update on those initial tasks we
set out to do.
On Wed, Mar 23, 2016 at 11:07 AM, Claus Ibsen <cl...@gmail.com> 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
>
Outstanding.
>
> c)
> Drop karaf 2.x.
> And move to karaf 4.x for all our testing.
>
Done
>
> d)
> Drop Jetty 8.x.
>
> This also requires to upgrade at least two components that currently
> rely on Jetty 8 to use Jetty 9.
>
Done
>
> e)
> Upgrade to latest Jetty 9.
> Jetty 9.3 (or is it 9.4) requires Java 1.8
>
Outstanding. There is some API breakings in jetty 9.2 to 9.3 (surprise
surprise).
>
> 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.
>
Done
>
> 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.
>
Done
>
> 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.
>
A lot has been done, thanks a lot to Andrea who have done most of the migration.
What is outstanding is to generate/update the EIP documentation for
all their options in a table, just as we do for components.
This should not be hard to do, as we just do similar eg add some code
in the the mvn plugin, and add some markers in the .adoc file where it
should insert/update the table.
>
> 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.
>
Done
>
> 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.
>
Outstanding. I think this is somewhat big work but would be good if
some of the CXF guys would pickup this task.
The CXF with RS is "hurt" when its dragging in a old WS dependencies.
>
> k)
> Continue as usual by adding new components, data formats, fix bugs, and so on.
>
Yep this is ongoing and we got 8 new components already.
>
> l)
> Timeline. This release do not need to have 6-8 months timeframe. We
> could try to get this "stepping stone" release done sooner, so it can
> be released during/shortly after summer.
>
I think after the summer vacation would be good time. We usually do a
release around september/early october.
So lets try to aim for that.
> 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