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
