On Mon, Jan 24, 2011 at 4:59 PM, Mark Ford <m...@massfords.com> wrote: > 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. >
Ah yeah thats true. I think we once upgraded to junit4 in camel-core and hit some issues. But that was with an earlier version of junit 4. > 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/ >> > -- 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/
