camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Some thoughts about the architecture of camel
Date Tue, 19 Oct 2010 12:31:27 GMT
On 18 October 2010 10:43, 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
> 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 :)


Open Source Integration

View raw message