camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Date Sat, 26 Mar 2016 05:43:17 GMT

There was a comment on my blog about the Camel logo

Hey Claus; The OpenTSDB project ( 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

On Wed, Mar 23, 2016 at 11:07 AM, 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:
> 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
> -----------------
> @davsclaus
> Camel in Action 2:

Claus Ibsen
----------------- @davsclaus
Camel in Action 2:

View raw message