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. > 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 < >>> [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
