Hi guys
I have some stuff ready around Karaf 4 and OSGI 5/6 support.
I will share asap.
RegardsJB
-------- Original message --------
From: Antoine Toulme <anto...@toulme.name>
Date: 29/03/2016 08:36 (GMT+01:00)
To: dev@camel.apache.org
Subject: Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
> On Mar 25, 2016, at 10:42 PM, Claus Ibsen <claus.ib...@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 <anto...@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 <claus.ib...@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
