On 18 October 2010 10:43, Schneider Christian <[email protected]> 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
What benefits do you see for end users and component developers having to depend on at least 3 jars rather than one? One of the reasons I like camel-core as it is; its nice and simple and just works. You can build & run routes with some simple components using the single camel-core jar. (Just add camel-test to do testing). Sure there's some cyclic package dependencies. Given the large number of use cases in Camel (route design, testing, JAXB model, Java DSL and base set of components) its kinda hard to totally avoid those while having convention over configuration, decent defaults etc. I value ease of use for end users & component developers and backwards compatibility over cyclic dependency metrics any day :) -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
