camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Whytock <>
Subject Re: Some thoughts about the architecture of camel
Date Tue, 19 Oct 2010 13:48:18 GMT
Something of an outsider here, but I personally would like to see
camel-core broken into smaller pieces for the sake of my OSGi-based
app.  At the moment the camel-core .jar is larger than my entire app,
including the felix .jar.  I really like the idea of using camel, but
it makes me wince to more than double the size of my deployable
binary.  Surely there's something in camel-core that doesn't
absolutely have to be there for simple runtime use?


On Tue, Oct 19, 2010 at 9:31 AM, Richard Kettelerij
<> wrote:
> Concerning the 2.0 vs. 3.0 debate. I agree with James and Claus that it
> would be better to change the major version when you require Spring 3.0 and
> Java 6.
> To illustrate, I'm still stuck at Java 5 (we'll probably move to Java 6 in
> 2011 Q1), so upgrading to Camel 3.0 isn't possible. Nevertheless when Camel
> 3.0 is in development I would still love to see blocking issues being fixed
> on the 2.x branch. Changing the major version makes this possible (like you
> guys did with the 1.x branch).
> On Tue, Oct 19, 2010 at 2:59 PM, Schneider Christian <
>> wrote:
>> Hi James,
>> it is not absolutely necessary to split the jar into three jars. More
>> important is to have rules that say that a component developer should only
>> depdend on the API part and to check that the internal dependencies do not
>> have cycles between the three logical modules. The only disadvantage of not
>> breaking up camel core into three modules is that maven will not help you in
>> avoiding cycles which would be the case with separate modules. As the rules
>> can be checked with tools like structure 101 this is not too bad though.
>> I don´t think the cyclic depdencies are only a "metric". They are a real
>> problem when the code grows as you can not understand or change anything
>> isolated. To have three clearly defined parts in camel core that should not
>> have cycles between them is quite reasonable imho.
>> Especially I think the builders should be separated as they are not needed
>> at runtime. The builder pattern creates many cycles and it confuses people
>> who try to understand the runtime behaviour. Of course I do not speak
>> against builders and the dsl. They are extremely convenient and clear to use
>> for end users and make a good part of the appeal of camel.
>> So to sum it up I think breaking up camel-core logically is very important.
>> At the same time I understand that ease of use is a value that is probably
>> as important as a clear architecture. The good thing is that I am quite sure
>> that we can achieve both.
>> 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: James Strachan []
>> Gesendet: Dienstag, 19. Oktober 2010 14:31
>> An:
>> Betreff: Re: Some thoughts about the architecture of camel
>> >
>> > 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
>> -------
>> Open Source Integration

View raw message