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
