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 > > >
