Agree. I would also drop support for junit 3.
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
