Some thoughts about the architecture of camel

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Some thoughts about the architecture of camel

jstrachan
On 19 October 2010 13:59, Schneider Christian
<[hidden email]> 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.

I don't follow this comment. When would the builders and DSL be used
other than at runtime? Every use case I've seen of the builders and
DSLs is for runtime stuff; defining routes at runtime; often using
runtime dependency injection.

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|

Re: Some thoughts about the architecture of camel

Richard Kettelerij
In reply to this post by Schneider Christian
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 <
[hidden email]> 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 [mailto:[hidden email]]
> Gesendet: Dienstag, 19. Oktober 2010 14:31
> An: [hidden email]
> 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
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Some thoughts about the architecture of camel

Claus Ibsen-2
In reply to this post by Schneider Christian
On Tue, Oct 19, 2010 at 2:26 PM, Schneider Christian
<[hidden email]> wrote:
> If you consider spring and jdk a (somewhat) breaking change then a 3.0 version is the right thing of course. I don´t care too much if this version is called 2.6 or 3.0 ;-)
>
> In this case I would like to have the more advanced stuff in the 4.0 version. Do you think that is possible?
>

Yeah definitely. We all know that at some time the current
architecture needs change and a new major version such as 4.0 is a
good version to do that. Then we also have longer time to work on it,
and people on the current 2.x/3.x architecture can rest assured the
API stays compatible so their components and other 3rd party projects
integrating out of the box with Camel, still works as is.

And maybe at Camel 4, we got goodies from JDK7 we can leverage (NIO2,
ForkJoin) or there are some great other frameworks out there we can
let Camel depend upon.

Or maybe even the Scala stuff just good so compelling that we all got
hooked and rewrote camel-core in Scala.


> 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: Claus Ibsen [mailto:[hidden email]]
> Gesendet: Dienstag, 19. Oktober 2010 14:22
> An: [hidden email]
> Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel
>
> On Tue, Oct 19, 2010 at 1:47 PM, Daniel Kulp <[hidden email]> wrote:
>> On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
>>> Hi
>>>
>>> I think the idea is really great, but I think the timing for this is
>>> *not* the right spot.
>>
>>
>> Why not?
>>
>>>
>>> And by saying that I mean the goal of Camel 3.0 is to have a short
>>> development cycle (not like 2.0 which took a long time).
>>> And as a minimum (IMHO):
>>> - To upgrade to JDK 1.6+,
>>> - Spring 3.0+,
>>> - To optimize the router internally,
>>> - And to switch to slf4j logger (*)
>>> - Keeping backwards compatibility as much as possible with 2.x is paramount
>>
>> Umm..  Everything listed there could go into a 2.6 release.   I don't see any
>> reason for that to be what defines a 3.0 release.
>>
>
> Sorry but those changes are major. Changing the minimum supported JDK
> platform is.
> eg Spring 2.5 still supports JDK 1.4. Only Spring 3.0 is JDK 1.5+ only.
>
> We can't just change that mid stream.
>
> And we dont du usually do so many minor releases as you do with CXF,
> eg 2.2.1 -> 2.2.11
> At Camel we do 2.0, 2.1, 2.2, 2.3 etc.
>
>
>> If we are going to have a 3.0, lets get the work done that would need to be
>> done to provide a stable platform for the next year or so and provides the
>> API's and feature that are requried for the various new and exciting ideas
>> people are proposing.
>>
>
> Sorry but I think the community want an easy upgrade path for JDK 1.6
> / Spring 3.0 based on the current 2.x architecture.
>
> It works really well, easy to write custom components. Hence why we
> got so many now.
> And many 3rd party projects have integrated out of the box with Camel.
> And we would lose some if we keep changing the architecture.
>
> We should not do a "Tapestry" with the Camel project, and change the
> core at each major release.
>
>
>> Dan
>>
>>
>>> Switching to slf4j instead of commons logging, allows us to use the
>>> MDC logging feature.
>>> This allows us to push information to the logs such as message id,
>>> transaction id etc. which can more easily correlate logs, not only
>>> with Camel alone, but also with other projects such as ActiveMQ, SMX
>>> etc.
>>>
>>>
>>> On top of that we now have many 3rd party projects which integrate out
>>> of the box with Camel, so changing the package structure in camel-core
>>> will break their integration. Which means they may not take up the
>>> effort to support both Camel 2.x/3.x.
>>>
>>> However I do think we should take the effort and pick up the low
>>> hanging fruits. I am sure there could be a couple of tangles which can
>>> be identified and fixed in Camel 3.0, without breaking backwards
>>> compatibility.
>>>
>>> I think doing this is something for Camel 4 or 5 or 6 (or whatever
>>> future version it may be) when or if we change to use Scala and use
>>> some other framework as foundation. There are cool stuff being
>>> developed for ActiveMQ 6 which are potential as a backbone for route
>>> messages. And it has a much better threading model which Camel can
>>> benefit as well.
>>>
>>> Anyway practical works beats theory, so setting up a branch in the
>>> sandbox to do experiments is a great idea.
>>>
>>> But its very important that we keep backwards compatibility with Camel
>>> 3.0. There are so many people started using Camel 2.x now so we should
>>> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
>>> 2.x but now on JDK 1.6 and with X other internal upgrades.
>>>
>>> Okay my first cup of coffee is ready, so beware this mail was written
>>> before I got "my first fix".
>>>
>>> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <[hidden email]> wrote:
>>> > I changed the thread name to [discuss].
>>> >
>>> > I like that idea and it's something we contemplated in the past. This
>>> > will bring back the idea of getting the dsl out of core as well.
>>> >
>>> > What I'd propose Christian is to add your proposal to the roadmap [1]. I
>>> > will do the same for the dsl idea. There at least 2 ideas for dsl's
>>> > built on top of the camel dsl (scheduling and debugging) that make me
>>> > even more interested in coming up with a better solution.
>>> >
>>> > Once we get some traction on the main refactoring ideas I'd suggest
>>> > starting one (or more) branches and start hacking, because there's not a
>>> > whole lot of time left if we want to meet our target.
>>> >
>>> > Cheers,
>>> > Hadrian
>>> >
>>> > [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>> >
>>> > On Oct 18, 2010, at 5:43 AM, 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 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
>>> >>
>>> >> These should be structured in a way that these big building blocks do
>>> >> not have cyclic dependencies. Any other cycles can be ignored in this
>>> >> step.
>>> >>
>>> >> As allowed depdencies I propose ( "->" means may use, depends on):
>>> >>
>>> >> * -> api
>>> >> end user config -> builder
>>> >> builder -> impl
>>> >>
>>> >> I think the first thing we should do is to discuss and reach a consensus
>>> >> about a basic architecure and rules like above. Then the next step is
>>> >> to assign each package of core to one of the basic parts. Then the next
>>> >> step is to resolve cycles between the parts.
>>> >>
>>> >> What do you think about these ideas?
>>> >>
>>> >> Thanks
>>> >>
>>> >> 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
>>
>> --
>> Daniel Kulp
>> [hidden email]
>> http://dankulp.com/blog
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>



--
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Reply | Threaded
Open this post in threaded view
|

Re: Some thoughts about the architecture of camel

Donald Whytock
In reply to this post by Richard Kettelerij
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?

Don


On Tue, Oct 19, 2010 at 9:31 AM, Richard Kettelerij
<[hidden email]> 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 <
> [hidden email]> 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 [mailto:[hidden email]]
>> Gesendet: Dienstag, 19. Oktober 2010 14:31
>> An: [hidden email]
>> 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
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Some thoughts about the architecture of camel

hadrian
In reply to this post by jstrachan
The benefit if allowing developers to have their dsl that extends the camel dsl. I get asked this question now and then (last time yesterday).
The only way to do it now is to have a separate dsl on top of the camel dsl. And the dsl is not that unified and you know it.

Hadrian


On Oct 19, 2010, at 8:34 AM, James Strachan wrote:

> On 18 October 2010 18:28, Hadrian Zbarcea <[hidden email]> wrote:
>> I changed the thread name to [discuss].
>>
>> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>
> What benefits does that have BTW? IMHO more dependencies for no actual
> gain has negative value.
>
> FWIW early camel had Java DSL separate from the JAXB model and it was
> a maintenance nightmare which is why we unified it into the same
> model.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/

Reply | Threaded
Open this post in threaded view
|

Re: Some thoughts about the architecture of camel

hadrian
In reply to this post by Richard Kettelerij
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.

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 <
> [hidden email]> 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 [mailto:[hidden email]]
>> Gesendet: Dienstag, 19. Oktober 2010 14:31
>> An: [hidden email]
>> 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
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Some thoughts about the architecture of camel

hadrian
In reply to this post by Claus Ibsen-2
If you think it's a good idea, and I agree, then 3.0 *is* the right time to do it. It's some 5-6 months away, there's plenty of time and I expect us to get a lot of help from the growing community.

Pushing this for 4.0 is much less realistic, we won't have another major release in 2011. I also agree that we should be backwards compatible as much as possible, but the truth is this is a major version and should come with major improvements. Moving to a major release of a dependent jar, is not a major improvement we do it all the time (even if the dependency is spring).

We need to first agree how 3.0 will be a major improvement. Setting a release time and have that contain whatever we manage to code until then sounds to me like Microsoft in its early days.

Hadrian


On Oct 19, 2010, at 12:23 AM, Claus Ibsen wrote:

> Hi
>
> I think the idea is really great, but I think the timing for this is
> *not* the right spot.
>
> And by saying that I mean the goal of Camel 3.0 is to have a short
> development cycle (not like 2.0 which took a long time).
> And as a minimum (IMHO):
> - To upgrade to JDK 1.6+,
> - Spring 3.0+,
> - To optimize the router internally,
> - And to switch to slf4j logger (*)
> - Keeping backwards compatibility as much as possible with 2.x is paramount
>
> Switching to slf4j instead of commons logging, allows us to use the
> MDC logging feature.
> This allows us to push information to the logs such as message id,
> transaction id etc. which can more easily correlate logs, not only
> with Camel alone, but also with other projects such as ActiveMQ, SMX
> etc.
>
>
> On top of that we now have many 3rd party projects which integrate out
> of the box with Camel, so changing the package structure in camel-core
> will break their integration. Which means they may not take up the
> effort to support both Camel 2.x/3.x.
>
> However I do think we should take the effort and pick up the low
> hanging fruits. I am sure there could be a couple of tangles which can
> be identified and fixed in Camel 3.0, without breaking backwards
> compatibility.
>
> I think doing this is something for Camel 4 or 5 or 6 (or whatever
> future version it may be) when or if we change to use Scala and use
> some other framework as foundation. There are cool stuff being
> developed for ActiveMQ 6 which are potential as a backbone for route
> messages. And it has a much better threading model which Camel can
> benefit as well.
>
> Anyway practical works beats theory, so setting up a branch in the
> sandbox to do experiments is a great idea.
>
> But its very important that we keep backwards compatibility with Camel
> 3.0. There are so many people started using Camel 2.x now so we should
> keep them happy with an easy upgrade path. Eg Camel 3.0 is just like
> 2.x but now on JDK 1.6 and with X other internal upgrades.
>
> Okay my first cup of coffee is ready, so beware this mail was written
> before I got "my first fix".
>
>
>
> On Mon, Oct 18, 2010 at 7:28 PM, Hadrian Zbarcea <[hidden email]> wrote:
>> I changed the thread name to [discuss].
>>
>> I like that idea and it's something we contemplated in the past. This will bring back the idea of getting the dsl out of core as well.
>>
>> What I'd propose Christian is to add your proposal to the roadmap [1]. I will do the same for the dsl idea. There at least 2 ideas for dsl's built on top of the camel dsl (scheduling and debugging) that make me even more interested in coming up with a better solution.
>>
>> Once we get some traction on the main refactoring ideas I'd suggest starting one (or more) branches and start hacking, because there's not a whole lot of time left if we want to meet our target.
>>
>> Cheers,
>> Hadrian
>>
>> [1] https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Roadmap
>>
>>
>>
>> On Oct 18, 2010, at 5:43 AM, 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 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
>>>
>>> These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.
>>>
>>> As allowed depdencies I propose ( "->" means may use, depends on):
>>>
>>> * -> api
>>> end user config -> builder
>>> builder -> impl
>>>
>>> I think the first thing we should do is to discuss and reach a consensus about a basic architecure and rules like above. Then the next step is to assign each package of core to one of the basic parts. Then the next step is to resolve cycles between the parts.
>>>
>>> What do you think about these ideas?
>>>
>>> Thanks
>>>
>>> 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
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Some thoughts about the architecture of camel

jstrachan
In reply to this post by hadrian
On 19 October 2010 14:51, Hadrian Zbarcea <[hidden email]> wrote:
> The benefit if allowing developers to have their dsl that extends the camel dsl. I get asked this question now and then (last time yesterday).
> The only way to do it now is to have a separate dsl on top of the camel dsl.

Huh? Anyone can define any DSL in any class anywhere and use as much
or as little of the Camel DSL as they like. Thats not an argument for
separating the Camel DSL from the JAXB model.


> And the dsl is not that unified and you know it.

Moving it away from the JAXB model will help unify the DSL how exactly?


--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|

Re: Some thoughts about the architecture of camel

Claus Ibsen-2
In reply to this post by hadrian
On Tue, Oct 19, 2010 at 3:55 PM, Hadrian Zbarcea <[hidden email]> 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.

Now that gets messy if Camel 2.6 is suddenly something 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.).

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 think better is to have a discussion and make a decision regarding jdk5 support after the survey results are final.
>
> 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 <
>> [hidden email]> 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 [mailto:[hidden email]]
>>> Gesendet: Dienstag, 19. Oktober 2010 14:31
>>> An: [hidden email]
>>> 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
>>> -------
>>> http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>> http://fusesource.com/
>>>
>
>



--
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Some thoughts about the architecture of camel

jstrachan
In reply to this post by hadrian
On 19 October 2010 15:06, Hadrian Zbarcea <[hidden email]> wrote:
> If you think it's a good idea, and I agree, then 3.0 *is* the right time to do it. It's some 5-6 months away, there's plenty of time and I expect us to get a lot of help from the growing community.
>
> Pushing this for 4.0 is much less realistic, we won't have another major release in 2011. I also agree that we should be backwards compatible as much as possible, but the truth is this is a major version and should come with major improvements. Moving to a major release of a dependent jar, is not a major improvement we do it all the time (even if the dependency is spring).
>
> We need to first agree how 3.0 will be a major improvement.

We've already said, moving (like many of our dependencies) to Spring 3
and JDK 6 is a pretty big jump folks need to be aware of; its not a
minor incremental feature release.


> Setting a release time and have that contain whatever we manage to code until then sounds to me like Microsoft in its early days.

I've no idea what you're talking about to be honest. Why are you so
hung up with clinging to 2.6 when we're making a clear, big dependency
jump to Java 6 and Spring 3?

Try putting yourself in the position of a user; in Camel up to now you
can move from 2.x to 2.(x+1) without worrying too much about it, it
mostly just works. For 3.x we want folks to ponder for second about
JDK and Spring dependencies. OK?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Some thoughts about the architecture of camel

hadrian
I feel that we're mostly in violent agreement :). Comments inline.

Hadrian

On Oct 19, 2010, at 10:21 AM, James Strachan wrote:

> On 19 October 2010 15:06, Hadrian Zbarcea <[hidden email]> wrote:
>> If you think it's a good idea, and I agree, then 3.0 *is* the right time to do it. It's some 5-6 months away, there's plenty of time and I expect us to get a lot of help from the growing community.
>>
>> Pushing this for 4.0 is much less realistic, we won't have another major release in 2011. I also agree that we should be backwards compatible as much as possible, but the truth is this is a major version and should come with major improvements. Moving to a major release of a dependent jar, is not a major improvement we do it all the time (even if the dependency is spring).
>>
>> We need to first agree how 3.0 will be a major improvement.
>
> We've already said, moving (like many of our dependencies) to Spring 3
> and JDK 6 is a pretty big jump folks need to be aware of; its not a
> minor incremental feature release.
I meant camel 3.0, right?

>> Setting a release time and have that contain whatever we manage to code until then sounds to me like Microsoft in its early days.
>
> I've no idea what you're talking about to be honest. Why are you so
> hung up with clinging to 2.6 when we're making a clear, big dependency
> jump to Java 6 and Spring 3?
I am not clinging to anything, I stated that moving to jdk6 is very possible in 2.6, or 2.7, or 3.0. Not so much for a maintenance release like 2.5.x for instance. Maybe we should consider having more maintenance releases like other projects (amq for instance). That said, personally I would love to move to jdk6 as soon as possible (hence my mentioning of camel 2.6). I had quite a bunch of failing java5 builds that I wasted time on with this release, and almost all developers use only java6 anyway. What java version are you using?

>
> Try putting yourself in the position of a user; in Camel up to now you
> can move from 2.x to 2.(x+1) without worrying too much about it, it
> mostly just works. For 3.x we want folks to ponder for second about
> JDK and Spring dependencies. OK?
Oh, believe me, I do :).

Fair enough, I agree with that. And while they're at it, they can still use 2.x for as long as they want, 2.x will be actively maintained until at least the and of 2011, we discussed that.
There is also no absolute must to be fully backwards compatible in camel 3.0. Heck, in some respects we are not fully backwards compatible between minor releases. Highly desired though, I agree.

On top of all that, there is no agreement on what should be done in camel 3.0 (as the wiki page clearly states as well). People are throwing in proposals, and now's definitely the right time, and we are respectfully considering them, and then we'll make decisions based on lazy consensus or other vote. I find the camel community a highly educated bunch, we can talk each other into (or out of) different proposals and solutions.

Let's discuss our proposals and options. If anybody has other proposals, put them on the table. I hope we can clarify most of it in the next weeks and start hacking. Apachecon would be a great place to meet face to face and agree on details, btw.

Cheers,
Hadrian

>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/

Reply | Threaded
Open this post in threaded view
|

Re: Some thoughts about the architecture of camel

hadrian
In reply to this post by Claus Ibsen-2
Comments inline.

Hadrian

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

> On Tue, Oct 19, 2010 at 3:55 PM, Hadrian Zbarcea <[hidden email]> 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 1.5


>> 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 <
>>> [hidden email]> 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 [mailto:[hidden email]]
>>>> Gesendet: Dienstag, 19. Oktober 2010 14:31
>>>> An: [hidden email]
>>>> 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
>>>> -------
>>>> http://macstrac.blogspot.com/
>>>>
>>>> Open Source Integration
>>>> http://fusesource.com/
>>>>
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus

Reply | Threaded
Open this post in threaded view
|

Re: Some thoughts about the architecture of camel

hadrian
Here's another thought.

We will continue to support 2.x for at least another year. Would it be less confusing if we released 2.6 in Dec, and 2.6.x in 2011 (when needed) on jdk 1.5 and the other 2.7 and up releases on jdk 1.6 only? Give people enough heads up to get used to the idea?

How does that sound?

Hadrian


>> 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 1.5



Reply | Threaded
Open this post in threaded view
|

Re: Some thoughts about the architecture of camel

jbonofre
Hi Hadrian,

+1

for project integrating Camel (such as ServiceMix), it will be more
flexible in that way.

Regards
JB

On 10/19/2010 06:03 PM, Hadrian Zbarcea wrote:

> Here's another thought.
>
> We will continue to support 2.x for at least another year. Would it be less confusing if we released 2.6 in Dec, and 2.6.x in 2011 (when needed) on jdk 1.5 and the other 2.7 and up releases on jdk 1.6 only? Give people enough heads up to get used to the idea?
>
> How does that sound?
>
> Hadrian
>
>
>>> 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 1.5
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Some thoughts about the architecture of camel

Christian Schneider
In reply to this post by jstrachan
  I have no problem with a 3.0 release for spring and jkd upgrades.  I
also like the idea that camel 3.x needs spring 3.x.

To also be able to do some breaking changes in the near future I propose
to do a 4.0 release earlier than planned. I think end of Q2 2011 could
be reasonable. We can start experimenting in a branch asap and try to
settle on the featureset for 4.0 till end of Q1. Then we should have
enough time to make it stable.

Best regards

Christian


Am 19.10.2010 16:21, schrieb James Strachan:

> On 19 October 2010 15:06, Hadrian Zbarcea<[hidden email]>  wrote:
>> If you think it's a good idea, and I agree, then 3.0 *is* the right time to do it. It's some 5-6 months away, there's plenty of time and I expect us to get a lot of help from the growing community.
>>
>> Pushing this for 4.0 is much less realistic, we won't have another major release in 2011. I also agree that we should be backwards compatible as much as possible, but the truth is this is a major version and should come with major improvements. Moving to a major release of a dependent jar, is not a major improvement we do it all the time (even if the dependency is spring).
>>
>> We need to first agree how 3.0 will be a major improvement.
> We've already said, moving (like many of our dependencies) to Spring 3
> and JDK 6 is a pretty big jump folks need to be aware of; its not a
> minor incremental feature release.
>
>
>> Setting a release time and have that contain whatever we manage to code until then sounds to me like Microsoft in its early days.
> I've no idea what you're talking about to be honest. Why are you so
> hung up with clinging to 2.6 when we're making a clear, big dependency
> jump to Java 6 and Spring 3?
>
> Try putting yourself in the position of a user; in Camel up to now you
> can move from 2.x to 2.(x+1) without worrying too much about it, it
> mostly just works. For 3.x we want folks to ponder for second about
> JDK and Spring dependencies. OK?
>

--
----
http://www.liquid-reality.de

Reply | Threaded
Open this post in threaded view
|

Re: Some thoughts about the architecture of camel

Christian Schneider
In reply to this post by jstrachan
  I think I used runtime in the wrong context. What I meant is that you
only need  the builders when you set up a route. Then while it runs you
don´t need it anymore.
A component implementation should have no knowledge about the dsl that
created it. The advantage is then that the dsl can be changed without
touching the component.

That is why I think a component should only depend on some kind of api
part of camel core.
Also when the user creates his own processor then inside this
implementation he should not know about builders. He should be able to
introspect the existing but I don´t think he needs to change it at that
time.

Best Regards

Christian


Am 19.10.2010 15:22, schrieb James Strachan:

> On 19 October 2010 13:59, Schneider Christian
> <[hidden email]>  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.
> I don't follow this comment. When would the builders and DSL be used
> other than at runtime? Every use case I've seen of the builders and
> DSLs is for runtime stuff; defining routes at runtime; often using
> runtime dependency injection.
>

--
----
http://www.liquid-reality.de

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Some thoughts about the architecture of camel

hadrian
In reply to this post by Christian Schneider
I don't think the idea of 2 major releases in a year will fly. I am personally against it until somebody convinces me otherwise.

I agree as well, that camel should move to spring 3.0. I am not convinced that it absolutely implies a major release of camel (3.0). At this time I don't have a strong preference on this issue.

Hadrian


On Oct 19, 2010, at 12:34 PM, Christian Schneider wrote:

> I have no problem with a 3.0 release for spring and jkd upgrades.  I also like the idea that camel 3.x needs spring 3.x.
>
> To also be able to do some breaking changes in the near future I propose to do a 4.0 release earlier than planned. I think end of Q2 2011 could be reasonable. We can start experimenting in a branch asap and try to settle on the featureset for 4.0 till end of Q1. Then we should have enough time to make it stable.
>
> Best regards
>
> Christian
>
>
> Am 19.10.2010 16:21, schrieb James Strachan:
>> On 19 October 2010 15:06, Hadrian Zbarcea<[hidden email]>  wrote:
>>> If you think it's a good idea, and I agree, then 3.0 *is* the right time to do it. It's some 5-6 months away, there's plenty of time and I expect us to get a lot of help from the growing community.
>>>
>>> Pushing this for 4.0 is much less realistic, we won't have another major release in 2011. I also agree that we should be backwards compatible as much as possible, but the truth is this is a major version and should come with major improvements. Moving to a major release of a dependent jar, is not a major improvement we do it all the time (even if the dependency is spring).
>>>
>>> We need to first agree how 3.0 will be a major improvement.
>> We've already said, moving (like many of our dependencies) to Spring 3
>> and JDK 6 is a pretty big jump folks need to be aware of; its not a
>> minor incremental feature release.
>>
>>
>>> Setting a release time and have that contain whatever we manage to code until then sounds to me like Microsoft in its early days.
>> I've no idea what you're talking about to be honest. Why are you so
>> hung up with clinging to 2.6 when we're making a clear, big dependency
>> jump to Java 6 and Spring 3?
>>
>> Try putting yourself in the position of a user; in Camel up to now you
>> can move from 2.x to 2.(x+1) without worrying too much about it, it
>> mostly just works. For 3.x we want folks to ponder for second about
>> JDK and Spring dependencies. OK?
>>
>
> --
> ----
> http://www.liquid-reality.de
>

Reply | Threaded
Open this post in threaded view
|

Re: Some thoughts about the architecture of camel

Willem.Jiang
Administrator
In reply to this post by hadrian
On 10/19/10 11:36 PM, Hadrian Zbarcea wrote:

> Comments inline.
>
> Hadrian
>
> On Oct 19, 2010, at 10:19 AM, Claus Ibsen wrote:
>
>> On Tue, Oct 19, 2010 at 3:55 PM, Hadrian Zbarcea<[hidden email]>  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.
>
Just like the Spring 3 supports JDK5, but the Spring 2.x also has some
modules that can only run with JDK5. It make sense to announce Camel 3.x
only supports JDK6, and it could be easy for us to clean up the backward
compatible codes (to support Spring 2.x, JDK 5) in Camel 3.

>
>> 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?
We are talking about breaking the backward compatible of the most
popular third part libs, and it's a major release thing.

>
>> 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 1.5
>
>
>>> 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.
I have strong feeling that most user are still using JDK 1.5, but it
don't mean we can't upgrade to JDK 1.6. We can keep providing some
candies in Camel 3.x for user to use :)

>
>
>>>
>>> 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<
>>>> [hidden email]>  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 [mailto:[hidden email]]
>>>>> Gesendet: Dienstag, 19. Oktober 2010 14:31
>>>>> An: [hidden email]
>>>>> 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
>>>>> -------
>>>>> http://macstrac.blogspot.com/
>>>>>
>>>>> Open Source Integration
>>>>> http://fusesource.com/
>>>>>
>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>
>


--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
12