camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: Some thoughts about the architecture of camel
Date Tue, 19 Oct 2010 13:55:54 GMT
I think we should take this as a separate discussion. The partial results from the recent survey
(which I hope you did fill in)
show that not many still use java5. Given the problems it causes for the release, I see it
as a very good idea to move to jdk6 in camel 2.6. You can still use 2.5 for many months to
come, until you decide to upgrade to jdk6, for once, and then we can also have 2.5.x maintenance
releases (more rare I hope) for those still interested in using jdk5.

I think better is to have a discussion and make a decision regarding jdk5 support after the
survey results are final.


On 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