On Tuesday 19 October 2010 8:22:11 am Schneider Christian wrote: > +1 For having a 2.6 release like Dan proposed. As Claus said the new > release should be as backwards compatible as possbile so I think it is not > necessary to increase the major release. Q1 2011 could be a good date for > this release.
I was actually thinking Dec for this if possible. I'm strongly considering making 2.2.12 the last 2.2.x release for CXF that I do which would be December. Need to present that to the CXF community, probably later today, but in any case, getting folks off of 2.2.x sooner is quite important. > +1 For doing the more advanced stuff like architecture of camel-core like I > proposed in the 3.0 release. As the 2.6 release would have the short term > stuff the release date could even be after Q1 2011 in my opinion. Late Q1 or early Q2 or so. That's 5-6 months which would be a reasonable dev effort for 3.0. IMO. Dan > > Best Regards > > 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 > > > -----Ursprüngliche Nachricht----- > Von: Daniel Kulp [mailto:[email protected]] > Gesendet: Dienstag, 19. Oktober 2010 13:47 > An: [email protected] > Cc: Claus Ibsen > Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel > > On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote: > > Hi > > > > I think the idea is really great, but I think the timing for this is > > *not* the right spot. > > Why not? > > > 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 > > Umm.. Everything listed there could go into a 2.6 release. I don't see > any reason for that to be what defines a 3.0 release. > > If we are going to have a 3.0, lets get the work done that would need to be > done to provide a stable platform for the next year or so and provides the > API's and feature that are requried for the various new and exciting ideas > people are proposing. > > Dan > > > 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 -- Daniel Kulp [email protected] http://dankulp.com/blog
