camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pavlovich <>
Subject Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Date Mon, 04 Apr 2016 15:20:31 GMT
On 3/24/16 3:55 PM, Claus Ibsen wrote:
> On Thu, Mar 24, 2016 at 6:24 PM, Krzysztof Sobkowiak
> <> 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 (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.

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] -
>> 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:
>>> 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 (
>> Apache ServiceMix Committer & PMC Member (
>> Senior Solution Architect @ Capgemini SSC (

View raw message