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<[email protected]> 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<
[email protected]> 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:[email protected]]
Gesendet: Dienstag, 19. Oktober 2010 14:31
An: [email protected]
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
