camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards
Date Sun, 30 Jan 2011 05:16:09 GMT
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.ibsen@gmail.com>
>>> wrote:
>>>> On Mon, Jan 24, 2011 at 4:29 PM, Hadrian Zbarcea<hzbarcea@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.ibsen@gmail.com>
wrote:
>>>>>>> Hi
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Jan 24, 2011 at 3:29 PM, Hadrian
>>>>>>> Zbarcea<hzbarcea@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: cibsen@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: james@fusesource.com
>>>>>> Web: http://fusesource.com
>>>>>> Twitter: jstrachan
>>>>>> Blog: http://macstrac.blogspot.com/
>>>>>> 
>>>>>> Open Source Integration
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> FuseSource
>>>> Email: cibsen@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


Mime
View raw message