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 2010/09/28 16:48:03 UTC

[DISCUSS] - Camel 3.0 - Lets get started

Hi

I think its a good time to get started on the Camel 3.0, when the
Camel 2.5 has been released.
If we do get started on this in october, then it gives us the time we
need to work on 3.0 so we can have a 3.0 release done early next year
(january 2011 would be the target month)

I propose to keep a short development cycle on 3.0 as opposed to 2.0
which took about 10+ months to develop.
The roadmap don't foster / require many major changes as 2.0 did.

We have some ideas / roadmap for 3.0 here, which has been out in the
opening for at least 6 months or more.
And we have asked for input on several occasions.
http://camel.apache.org/camel-30-roadmap.html

I propose to do a 3.0 release which has less focus on adding new end
users features, but more on internal upgrades and refactorings.
The biggest win would be #2 which would make Camel much more dynamic
at runtime allowing you to drop in interceptors, error handlers and
whatnot.
And have those come and go as you please in a much more dynamic way
than currently.

Then a 3.1 release can follow thereafter with the usual focus on
adding many new features and improvements.
And with the bugfixes found in the 3.0 release.


1)
The first goal we would like to set is
- JDK 1.6+ only
- Spring 3.0+ only

We want to leap to the next generation of Java and Spring. Dropping
support for JDK 1.5, which is EOL already.

2)
There are some optimizations and making the Camel routing more
dynamically that we should work on in the "engine room".

3)
Tighten up DSL. If you press ctrl + space in the DSL you get a big
list because many definitions extends ProcessorDefinition.
We can break up this and have configuration for onException,
transacted, policy, interceptor, onCompletion (all the cross cutting
concerns) into
a separate definition, which would help reduce the big list the end
user see when pressing ctrl + space. The idea is to have those
configurations
available in the start of the route. And then when you are done with
that, you get into the actual route processing steps, which then would
have
a shorted list when pressing ctrl + space.

4)
Support for asynchronous transactions

5)
seda/vm to leverage async routing engine.


And I am sure we continue adding / maintain the 2.x release as well,
so we will still add a lot of new features and improvements that we
usually do.
Just look at 2.5 which now have 220+ jira tickets resolved, since 2.4 release.



Any thoughts?

-- 
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

Re: [DISCUSS] - Camel 3.0 - Lets get started

Posted by Hadrian Zbarcea <hz...@gmail.com>.
Sounds great. I added a post [1] on the camel site announcing discontinued support for the 1.x branch and shifting the focus to 3.0.

Hadrian

[1] https://cwiki.apache.org/confluence/display/CAMEL/Index

On Sep 28, 2010, at 10:48 AM, Claus Ibsen wrote:

> Hi
> 
> I think its a good time to get started on the Camel 3.0, when the
> Camel 2.5 has been released.
> If we do get started on this in october, then it gives us the time we
> need to work on 3.0 so we can have a 3.0 release done early next year
> (january 2011 would be the target month)
> 
> I propose to keep a short development cycle on 3.0 as opposed to 2.0
> which took about 10+ months to develop.
> The roadmap don't foster / require many major changes as 2.0 did.
> 
> We have some ideas / roadmap for 3.0 here, which has been out in the
> opening for at least 6 months or more.
> And we have asked for input on several occasions.
> http://camel.apache.org/camel-30-roadmap.html
> 
> I propose to do a 3.0 release which has less focus on adding new end
> users features, but more on internal upgrades and refactorings.
> The biggest win would be #2 which would make Camel much more dynamic
> at runtime allowing you to drop in interceptors, error handlers and
> whatnot.
> And have those come and go as you please in a much more dynamic way
> than currently.
> 
> Then a 3.1 release can follow thereafter with the usual focus on
> adding many new features and improvements.
> And with the bugfixes found in the 3.0 release.
> 
> 
> 1)
> The first goal we would like to set is
> - JDK 1.6+ only
> - Spring 3.0+ only
> 
> We want to leap to the next generation of Java and Spring. Dropping
> support for JDK 1.5, which is EOL already.
> 
> 2)
> There are some optimizations and making the Camel routing more
> dynamically that we should work on in the "engine room".
> 
> 3)
> Tighten up DSL. If you press ctrl + space in the DSL you get a big
> list because many definitions extends ProcessorDefinition.
> We can break up this and have configuration for onException,
> transacted, policy, interceptor, onCompletion (all the cross cutting
> concerns) into
> a separate definition, which would help reduce the big list the end
> user see when pressing ctrl + space. The idea is to have those
> configurations
> available in the start of the route. And then when you are done with
> that, you get into the actual route processing steps, which then would
> have
> a shorted list when pressing ctrl + space.
> 
> 4)
> Support for asynchronous transactions
> 
> 5)
> seda/vm to leverage async routing engine.
> 
> 
> And I am sure we continue adding / maintain the 2.x release as well,
> so we will still add a lot of new features and improvements that we
> usually do.
> Just look at 2.5 which now have 220+ jira tickets resolved, since 2.4 release.
> 
> 
> 
> Any thoughts?
> 
> -- 
> Claus Ibsen
> Apache Camel Committer
> 
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus