On Tue, Oct 19, 2010 at 6:44 AM, Johan Edstrom <[email protected]> wrote: > How do we help you? >
About Camel 3.0? Anyone who wants to contribute can of course help. We love contributions at Apache. And Johan just keep up a bit more and I am sure you got the attentions of the PMCs to come onboard. First I think we need Camel 2.5 to be shipped. Then Hadrian can setup the 2.x branch and ensure trunk is ready for Camel 3.0 development. A rough plan for tasks to do could be something like this - Then we can upgrade to JDK 1.6 and fix a few minor spots (eg IOException now accepts nested exception, no need to use IOHelper) - Removed @deprecated stuff from 2.x - Upgrade to Spring 3.0 - Add SPEL (from Spring 3.0) as language to Camel - There are potentially some code in the Camel spring namespace holder which now may be obsolete by Spring 3 (check upon that) - Upgrade to CXF 2.3 as people would like (eg it uses Jetty 7 and has better continuations) - Switch to use slf4j in camel-core, camel-spring and other important components - And gradually switch to slf4j in the other camel components - Use MDC in camel-core for enriching the logger with message id, tx id (bread crumb, to trace message) - Create camel-osgi-test for OSGi test kit After all this work we can start looking into one of the tougher pieces which is to optimize the internal router - Reduce the need for copying the Exchange while routing - Message facade with history and fix the useOriginalMessage - Make the cross cutting concerns more dynamic (currently they are statically woven into the route when the route is generated) Instead it ought to be dynamic applied, so its much easier to inject/remove interceptors, error handlers, and whatnot And a ton of stuff which I may forgot. And of course we will still continue doing the usual work of fixing bugs, adding new components, improvements and what else the community reports. In terms of "package tangle" there could be some low hanging fruits. There is a tool which can visualize the packages. Structure 101 which is really good at this. There are stuff which can be started already now, such as the camel-osgi-test which ought to be able to backport to Camel 2.x as well. We got some rough code in tests/camel-itest-osgi which "just" needs to be polished and moved into a new component. Okay getting ready for the 2nd cup now. > On Oct 18, 2010, at 10:42 PM, Claus Ibsen wrote: > >> On Tue, Oct 19, 2010 at 6:40 AM, Johan Edstrom <[email protected]> wrote: >>> Since you did not get your Coffee :) >>> Would you mind putting the hindrances up to the mere mortals? >>> >> >> What do you mean? >> >>> >>> On Oct 18, 2010, at 10:23 PM, Claus Ibsen wrote: >>> >>>> Hi >>>> >>>> I think the idea is really great, but I think the timing for this is >>>> *not* the right spot. >>>> >>>> And by saying that I mean the goal of Camel 3.0 is to have a short >>>> development cycle (not like 2.0 which took a long time). >>>> And as a minimum (IMHO): >>>> - To upgrade to JDK 1.6+, >>>> - Spring 3.0+, >>>> - To optimize the router internally, >>>> - And to switch to slf4j logger (*) >>>> - Keeping backwards compatibility as much as possible with 2.x is paramount >>>> >>>> Switching to slf4j instead of commons logging, allows us to use the >>>> MDC logging feature. >>>> This allows us to push information to the logs such as message id, >>>> transaction id etc. which can more easily correlate logs, not only >>>> with Camel alone, but also with other projects such as ActiveMQ, SMX >>>> etc. >>>> >>>> >>>> On top of that we now have many 3rd party projects which integrate out >>>> of the box with Camel, so changing the package structure in camel-core >>>> will break their integration. Which means they may not take up the >>>> effort to support both Camel 2.x/3.x. >>>> >>>> However I do think we should take the effort and pick up the low >>>> hanging fruits. I am sure there could be a couple of tangles which can >>>> be identified and fixed in Camel 3.0, without breaking backwards >>>> compatibility. >>>> >>>> I think doing this is something for Camel 4 or 5 or 6 (or whatever >>>> future version it may be) when or if we change to use Scala and use >>>> some other framework as foundation. There are cool stuff being >>>> developed for ActiveMQ 6 which are potential as a backbone for route >>>> messages. And it has a much better threading model which Camel can >>>> benefit as well. >>>> >>>> Anyway practical works beats theory, so setting up a branch in the >>>> sandbox to do experiments is a great idea. >>>> >>>> But its very important that we keep backwards compatibility with Camel >>>> 3.0. There are so many people started using Camel 2.x now so we should >>>> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like >>>> 2.x but now on JDK 1.6 and with X other internal upgrades. >>>> >>>> Okay my first cup of coffee is ready, so beware this mail was written >>>> before I got "my first fix". >>>> >>>> >>>> >>>> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <[email protected]> >>>> wrote: >>>>> I changed the thread name to [discuss]. >>>>> >>>>> I like that idea and it's something we contemplated in the past. This >>>>> will bring back the idea of getting the dsl out of core as well. >>>>> >>>>> What I'd propose Christian is to add your proposal to the roadmap [1]. I >>>>> will do the same for the dsl idea. There at least 2 ideas for dsl's built >>>>> on top of the camel dsl (scheduling and debugging) that make me even more >>>>> interested in coming up with a better solution. >>>>> >>>>> Once we get some traction on the main refactoring ideas I'd suggest >>>>> starting one (or more) branches and start hacking, because there's not a >>>>> whole lot of time left if we want to meet our target. >>>>> >>>>> Cheers, >>>>> Hadrian >>>>> >>>>> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap >>>>> >>>>> >>>>> >>>>> On Oct 18, 2010, at 5:43 AM, Schneider Christian wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I will have some free time in december as I am changing my employer. So >>>>>> I am planning to work a little on some architectural improvements for >>>>>> camel 3.0.0. As these things are very critical to the stability of camel >>>>>> I would like to get feedback before I start any substantial work. >>>>>> >>>>>> As you surely know currently camel-core is quite tangled. So it is quite >>>>>> difficult where to start. Some time ago I proposed some improvements to >>>>>> simply reduce those dependency cycles. As I now know a lot more about >>>>>> camel I think that this simple aproach will not really work. So this >>>>>> time I want to do this a little more structured. So I start with two >>>>>> simple goals: >>>>>> >>>>>> "The camel components should know as little as possible about camel core" >>>>>> >>>>>> "The classes needed to setup camel should be separate from the things >>>>>> needed at run time" >>>>>> >>>>>> So why should this be important? Currently components depend on >>>>>> camel-core as a whole and there are no further rules which classes the >>>>>> components should use and which classes should be private to core. Even >>>>>> classes from the impl package are needed. So this means that any >>>>>> refactoring we do in camel core could affect all components. As camel is >>>>>> growing steadily this can become quite problematic. >>>>>> >>>>>> So my idea would be to split camel-core into three parts: >>>>>> >>>>>> api, builder, impl >>>>>> >>>>>> These should be structured in a way that these big building blocks do >>>>>> not have cyclic dependencies. Any other cycles can be ignored in this >>>>>> step. >>>>>> >>>>>> As allowed depdencies I propose ( "->" means may use, depends on): >>>>>> >>>>>> * -> api >>>>>> end user config -> builder >>>>>> builder -> impl >>>>>> >>>>>> I think the first thing we should do is to discuss and reach a consensus >>>>>> about a basic architecure and rules like above. Then the next step is to >>>>>> assign each package of core to one of the basic parts. Then the next >>>>>> step is to resolve cycles between the parts. >>>>>> >>>>>> What do you think about these ideas? >>>>>> >>>>>> Thanks >>>>>> >>>>>> Christian >>>>>> >>>>>> Christian Schneider >>>>>> Informationsverarbeitung >>>>>> Business Solutions >>>>>> Handel und Dispatching >>>>>> >>>>>> Tel : +49-(0)721-63-15482 >>>>>> >>>>>> EnBW Systeme Infrastruktur Support GmbH >>>>>> Sitz der Gesellschaft: Karlsruhe >>>>>> Handelsregister: Amtsgericht Mannheim - HRB 108550 >>>>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck >>>>>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>> >>> Johan Edstrom >>> >>> [email protected] >>> >>> They that can give up essential liberty to purchase a little temporary >>> safety, deserve neither liberty nor safety. >>> >>> Benjamin Franklin, Historical Review of Pennsylvania, 1759 >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> 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 > > Johan Edstrom > > [email protected] > > They that can give up essential liberty to purchase a little temporary > safety, deserve neither liberty nor safety. > > Benjamin Franklin, Historical Review of Pennsylvania, 1759 > > > > > > -- 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
