Could you post a "LOW HANGING FRUIT" Page that us mortals could start hitting?
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
