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