Changing Camel to 3.x matches the Spring naming conventions sounds a good enough idea in itself; but adding in the JDK 5->6 change too, then 3.0 sounds like a no brainer to me.
Then Camel 2.x works with Spring 2.x and Camel 3.x works with Spring 3.x; nice and easy to remember. If folks want to experiment with a non-backwards compatible 4.x version of Camel we can always have parallel experimental branches where folks can play; as progress is made we can weigh up the strengths and weaknesses of the different refactorings folks experiment with. On 19 October 2010 13:26, Schneider Christian <[email protected]> wrote: > If you consider spring and jdk a (somewhat) breaking change then a 3.0 > version is the right thing of course. I don´t care too much if this version > is called 2.6 or 3.0 ;-) > > In this case I would like to have the more advanced stuff in the 4.0 version. > Do you think that is possible? > > 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: Claus Ibsen [mailto:[email protected]] > Gesendet: Dienstag, 19. Oktober 2010 14:22 > An: [email protected] > Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel > > On Tue, Oct 19, 2010 at 1:47 PM, Daniel Kulp <[email protected]> wrote: >> 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. >> > > Sorry but those changes are major. Changing the minimum supported JDK > platform is. > eg Spring 2.5 still supports JDK 1.4. Only Spring 3.0 is JDK 1.5+ only. > > We can't just change that mid stream. > > And we dont du usually do so many minor releases as you do with CXF, > eg 2.2.1 -> 2.2.11 > At Camel we do 2.0, 2.1, 2.2, 2.3 etc. > > >> 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. >> > > Sorry but I think the community want an easy upgrade path for JDK 1.6 > / Spring 3.0 based on the current 2.x architecture. > > It works really well, easy to write custom components. Hence why we > got so many now. > And many 3rd party projects have integrated out of the box with Camel. > And we would lose some if we keep changing the architecture. > > We should not do a "Tapestry" with the Camel project, and change the > core at each major release. > > >> 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 >> > > > > -- > 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 > -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
