Why create a branch now? The branch should be created off of the camel-2.6.0 tag. Hence it can be created at any time. It must not be created off of trunk. That time is the first time somebody wants to apply a fix on both the trunk and 2.6.x moving forward. Is that the case?
Hadrian On Jan 29, 2011, at 10:19 PM, Willem Jiang wrote: > It looks like we need to create a new camel 2.6.x branch from now on, > Current camel trunk 2.7.0 can't build with JDK 1.5[1] > > If we are planing to drop the JDK 1.5.0 support after Camel 2.6.0, it's time > to do it. > > [1]https://hudson.apache.org/hudson/view/A-F/view/Camel/job/Camel.trunk.fulltest/ > > Willem > > On 1/25/11 2:55 AM, Christian Schneider wrote: >> +1 for doing the branch. >> >> As for the tests I think a good practice would be to move them >> gradually. So whenever you touch a test you convert it. Of course we >> could also simply leave them as they are. >> >> Christian >> >> >> Am 24.01.2011 16:59, schrieb Mark Ford: >>> I would like to see a branch of camel 2.6.x that was kept up to date >>> with major bug fixes since I have some projects that are stuck on 1.5. >>> >>> As for JUnit, I don't see what needs to be done since it's backwards >>> compatible, right? The annotations are much cleaner but I don't see a >>> pressing need to migrate existing tests. >>> >>> On Mon, Jan 24, 2011 at 10:33 AM, Claus Ibsen<claus.ib...@gmail.com> >>> wrote: >>>> On Mon, Jan 24, 2011 at 4:29 PM, Hadrian Zbarcea<hzbar...@gmail.com> >>>> wrote: >>>>> Agree. >>>>> >>>>> I would also drop support for junit 3. >>>>> >>>> +1 >>>> >>>> Good idea lets add that. I think camel-core currently uses JUnit 3 for >>>> testing. Its approx 3300 unit tests to be migrated to @Test :) >>>> >>>> And there is about 700 tests in camel-spring >>>> Spring 2.0/2.5 does not support some of the later JUnit 4 releases. I >>>> think JUnit 4.5+ onwards causes Spring 2.5/2.0 to not work. >>>> >>>> So its a bit of work to do. But that should be doable. Just a bit of >>>> hard work. >>>> >>>> >>>> >>>>> As soon as we vote the 2.6.0 release we can start the upgrades. If >>>>> we decide to keep supporting 2.6.x, we'll create a branch off the >>>>> tag when needed. >>>>> >>>>> Hadrian >>>>> >>>>> >>>>> On Jan 24, 2011, at 10:01 AM, James Strachan wrote: >>>>> >>>>>> +1. >>>>>> >>>>>> I'd also like us to make this dependency upgrade ASAP; then we can >>>>>> work on the longer term changes to Camel at a slower pace& not be >>>>>> faced with dual-patching pain (back porting to slf4j and >>>>>> commons-logging in parallel etc). >>>>>> >>>>>> On 24 January 2011 14:49, Claus Ibsen<claus.ib...@gmail.com> wrote: >>>>>>> Hi >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Jan 24, 2011 at 3:29 PM, Hadrian >>>>>>> Zbarcea<hzbar...@gmail.com> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Camel-2.6.0 is being build while I write this. One of the things >>>>>>>> that was informally discussed and I am formally proposing now is >>>>>>>> dropping support for java 1.5 starting with the next release. It >>>>>>>> hasn't been supported for a while and the survey showed almost no >>>>>>>> interest in it. >>>>>>>> >>>>>>>> If needed (which I personally doubt), we could have 2.6.x >>>>>>>> releases on java 1.5. Other Apache projects already dropped >>>>>>>> support for java 1.x on trunk as well. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Hadrian >>>>>>> Yeah I think its a good time to discuss this, now that Camel 2.6 >>>>>>> is one its way. >>>>>>> >>>>>>> We had the Camel 3.0 roadmap outlined here >>>>>>> http://camel.apache.org/camel-30-roadmap.html >>>>>>> >>>>>>> >>>>>>> In light of this I would like to propose the idea of moving some of >>>>>>> the todo's from the Camel 3.0 roadmap into Camel 2.7, specifically: >>>>>>> - switching to slf4j as logger >>>>>>> - upgrading to jdk 1.6 as minimum >>>>>>> - upgrading to spring 3.0 as minimum >>>>>>> >>>>>>> >>>>>>> The reason for this is that many enterprise companies is asking for >>>>>>> this move. They are not using JDK 1.5 at all. They want to leverage >>>>>>> some of the new stuff in Spring 3. And most importantly they want to >>>>>>> use MDC with the logger (http://logback.qos.ch/manual/mdc.html). >>>>>>> Switching to slf4j allows us to offer MDC capabilities. Not only with >>>>>>> Apache Camel but also with some of the related Apache projects >>>>>>> such as >>>>>>> ActiveMQ, ServiceMix and possibly CXF. ActiveMQ and SMX will >>>>>>> switch to >>>>>>> using sfl4j in their next major releases (ActiveMQ 5.5, ServiceMix >>>>>>> 4.4). Also ActiveMQ 5.5 is upgrading to JDK 1.6 / spring 3.0 as >>>>>>> minimum. >>>>>>> >>>>>>> What the MDC then allows enterprise companies is to much better >>>>>>> correlate and trace messages as they are being processed, not only >>>>>>> within Camel itself, but also between the projects. That allows >>>>>>> you to >>>>>>> much better diagnose and visualize what's going on with the messages. >>>>>>> See more details at: http://logback.qos.ch/manual/mdc.html. >>>>>>> >>>>>>> >>>>>>> If we agree upon this we can implement this in Camel 2.7.0 in the >>>>>>> next >>>>>>> release cycle (3 months). >>>>>>> >>>>>>> >>>>>>> And if we are concerned about JDK 1.5 / spring 2.x users we can keep >>>>>>> Camel 2.6.0 as a branch and merge important bug fixes to this branch. >>>>>>> And thus be able to release a patch releases (2.6.1, 2.6.2 and so on) >>>>>>> at Apache? >>>>>>> >>>>>>> >>>>>>> That allows us in the longer run to plan for Camel 3.0 and do the >>>>>>> architectural refactorings that Christian have suggested. >>>>>>> http://camel.465427.n5.nabble.com/Some-thoughts-about-the-architecture-of-camel-td3217183.html >>>>>>> >>>>>>> >>>>>>> As well as implement the performance optimizations in the routing >>>>>>> engine, which may entail a slight API chance / behavior on the EIPs >>>>>>> and Exchange. And some of the other improvements we have listed on >>>>>>> the roadmap. >>>>>>> >>>>>>> That kind of work requires longer time to do. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Claus Ibsen >>>>>>> ----------------- >>>>>>> FuseSource >>>>>>> Email: cib...@fusesource.com >>>>>>> Web: http://fusesource.com >>>>>>> Twitter: davsclaus >>>>>>> Blog: http://davsclaus.blogspot.com/ >>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/ >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> James >>>>>> ------- >>>>>> FuseSource >>>>>> Email: ja...@fusesource.com >>>>>> Web: http://fusesource.com >>>>>> Twitter: jstrachan >>>>>> Blog: http://macstrac.blogspot.com/ >>>>>> >>>>>> Open Source Integration >>>>> >>>> >>>> >>>> -- >>>> Claus Ibsen >>>> ----------------- >>>> FuseSource >>>> Email: cib...@fusesource.com >>>> Web: http://fusesource.com >>>> Twitter: davsclaus >>>> Blog: http://davsclaus.blogspot.com/ >>>> Author of Camel in Action: http://www.manning.com/ibsen/ >>>> >> > > > -- > Willem > ---------------------------------- > FuseSource > Web: http://www.fusesource.com > Blog: http://willemjiang.blogspot.com (English) > http://jnn.javaeye.com (Chinese) > Twitter: willemjiang
