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 15:36:55 GMT
Comments inline.


On Oct 19, 2010, at 10:19 AM, Claus Ibsen wrote:

> On Tue, Oct 19, 2010 at 3:55 PM, Hadrian Zbarcea <> wrote:
>> 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.
> Sorry but I think this message will really confuse end users and even our self.
> Having Camel 2.x = JDK 1.5 / Spring 2.5 / ( and Spring 3.0 support
> from Camel 2.3/4 onwards). Hey even Spring 2.0 is still support I
> think.
Why do you equate Camel 2.x with jdk 1.5 and spring 2.5? As you know camel-web, which we distribute,
*only* works with jdk 1.6.
We also use junit 3.8.2 and 4.8.1 and various versions of a bunch of dependent jars, that
get upgraded from a camel release to another.
Granted the jdk version is very important, but we made the decision of only supporting jdk
1.6 (for a subset of the components at least) when we added the jersey dependency.

> Now that gets messy if Camel 2.6 is suddenly something else.
What are you talking about. What else?

> Also in the light how we have always done releases at Apache. One
> major after the other. 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6 and so forth.
> We started maintenance mode of Camel 1.x in the 1.6 line (albeit Camel
> 1.6.1 should really have been Camel 1.7 since there so many changes in
> it.).
Point being?

> It will in fact start to confuse / scare people if Camel 2.5 is
> already in the "maintenance mode" and the next expected release would
> be Camel 2.5.1.
I promise to withdraw my proposal (which is not formal yet, but I intend to make it a formal
proposal once the survey results are out)
to only support jdk 1.6 from camel 2.6 onwards if I hear *one* developer (seriously) saying
that he'd be scared if:
* camel 2.6 and onwards on the 2.x line will only support jdk 1.6
* camel 2.5.x will continue to be maintained and supported on jdk 1.5
My thoughts are based on the intermediate results of the survey and the cost to support jdk

>> I think better is to have a discussion and make a decision regarding jdk5 support
after the survey results are final.
There, I am repeating myself.

>> Cheers,
>> Hadrian
>> 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
>>>> 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
>>>> 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
> -- 
> Claus Ibsen
> Apache Camel Committer
> Author of Camel in Action:
> Open Source Integration:
> Blog:
> Twitter:

View raw message