Quantcast

[DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

hadrian
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Jean-Baptiste Onofré
+1 to drop support for java 1.5.

FYI, if Apache Karaf 2.2.x supports Java 1.5, Apache Karaf 3.x will drop
the Java 1.5 also.

Regards
JB

On 01/24/2011 03:29 PM, Hadrian Zbarcea 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Claus Ibsen-2
In reply to this post by hadrian
Hi



On Mon, Jan 24, 2011 at 3:29 PM, Hadrian Zbarcea <[hidden email]> 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: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Claus Ibsen-2
In reply to this post by hadrian
On Mon, Jan 24, 2011 at 3:29 PM, Hadrian Zbarcea <[hidden email]> 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

By upgrading to JDK 1.6 we can also start to include components which
uses libaries that requires JDK 1.6+. For example the Apache Cassandra
project. We have a camel-cassandra project at github which the author
is willing to donate to Apache Camel when we are ready to include it.

I am sure there are other of the new cloud and no-sql frameworks which
would be interesting to have a Camel story and components out of the
box.


--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

James Strachan
In reply to this post by Claus Ibsen-2
+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 <[hidden email]> wrote:

> Hi
>
>
>
> On Mon, Jan 24, 2011 at 3:29 PM, Hadrian Zbarcea <[hidden email]> 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: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>



--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Christian Schneider-2
In reply to this post by hadrian
+1 For dropping java 1.5

Christian

-----Ursprüngliche Nachricht-----
Von: Hadrian Zbarcea [mailto:[hidden email]]
Gesendet: Montag, 24. Januar 2011 15:30
An: [hidden email]
Betreff: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Christian Schneider-2
In reply to this post by Claus Ibsen-2
+1 For all points.

I only have a question about the switch to slf4j. Does this mean we should convert all logging statements? Can this be automated?

Christian


-----Ursprüngliche Nachricht-----
Von: Claus Ibsen [mailto:[hidden email]]
Gesendet: Montag, 24. Januar 2011 15:49
An: [hidden email]
Betreff: Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Claus Ibsen-2
On Mon, Jan 24, 2011 at 4:22 PM, Christian Schneider
<[hidden email]> wrote:
> +1 For all points.
>
> I only have a question about the switch to slf4j. Does this mean we should convert all logging statements? Can this be automated?
>

Good question. Yes it can be automated. There is a tool for that:
http://www.slf4j.org/migrator.html

With the sfl4j API in camel-core we will then be able to start using MDC.

And the API has support for placeholders which makes it easier to use
for logging with parameters
http://www.slf4j.org/manual.html

And the Q about how not to log for best performance
http://www.slf4j.org/faq.html#logging_performance





> Christian
>
>
> -----Ursprüngliche Nachricht-----
> Von: Claus Ibsen [mailto:[hidden email]]
> Gesendet: Montag, 24. Januar 2011 15:49
> An: [hidden email]
> Betreff: Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards
>
> 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
>
>



--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

hadrian
In reply to this post by James Strachan
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 <[hidden email]> wrote:
>> Hi
>>
>>
>>
>> On Mon, Jan 24, 2011 at 3:29 PM, Hadrian Zbarcea <[hidden email]> 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: [hidden email]
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
>
>
>
> --
> James
> -------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: jstrachan
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Claus Ibsen-2
On Mon, Jan 24, 2011 at 4:29 PM, Hadrian Zbarcea <[hidden email]> 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 <[hidden email]> wrote:
>>> Hi
>>>
>>>
>>>
>>> On Mon, Jan 24, 2011 at 3:29 PM, Hadrian Zbarcea <[hidden email]> 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: [hidden email]
>>> Web: http://fusesource.com
>>> Twitter: davsclaus
>>> Blog: http://davsclaus.blogspot.com/
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>
>>
>>
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: [hidden email]
>> Web: http://fusesource.com
>> Twitter: jstrachan
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration
>
>



--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Christian Mueller
+1
I also like all the ideas. Let's open the tickets, if not yet done...
I would like to work on the "lowest hanging fruits" or as Claus sayes , the
"bit of hard work" ;-) - upgrading to JUnit 4. I suggest to use JUnit 4.7
because this is the version the Spring guys using currently.

Christian
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Mark Ford
In reply to this post by Claus Ibsen-2
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 <[hidden email]> wrote:

> On Mon, Jan 24, 2011 at 4:29 PM, Hadrian Zbarcea <[hidden email]> 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 <[hidden email]> wrote:
>>>> Hi
>>>>
>>>>
>>>>
>>>> On Mon, Jan 24, 2011 at 3:29 PM, Hadrian Zbarcea <[hidden email]> 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: [hidden email]
>>>> Web: http://fusesource.com
>>>> Twitter: davsclaus
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>
>>>
>>>
>>>
>>> --
>>> James
>>> -------
>>> FuseSource
>>> Email: [hidden email]
>>> Web: http://fusesource.com
>>> Twitter: jstrachan
>>> Blog: http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Claus Ibsen-2
On Mon, Jan 24, 2011 at 4:59 PM, Mark Ford <[hidden email]> 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 <[hidden email]> wrote:
>> On Mon, Jan 24, 2011 at 4:29 PM, Hadrian Zbarcea <[hidden email]> 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 <[hidden email]> wrote:
>>>>> Hi
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 24, 2011 at 3:29 PM, Hadrian Zbarcea <[hidden email]> 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: [hidden email]
>>>>> Web: http://fusesource.com
>>>>> Twitter: davsclaus
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> James
>>>> -------
>>>> FuseSource
>>>> Email: [hidden email]
>>>> Web: http://fusesource.com
>>>> Twitter: jstrachan
>>>> Blog: http://macstrac.blogspot.com/
>>>>
>>>> Open Source Integration
>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: [hidden email]
>> 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: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Christian Schneider
In reply to this post by Mark Ford
+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<[hidden email]>  wrote:
>> On Mon, Jan 24, 2011 at 4:29 PM, Hadrian Zbarcea<[hidden email]>  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<[hidden email]>  wrote:
>>>>> Hi
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 24, 2011 at 3:29 PM, Hadrian Zbarcea<[hidden email]>  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: [hidden email]
>>>>> Web: http://fusesource.com
>>>>> Twitter: davsclaus
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>
>>>>
>>>>
>>>> --
>>>> James
>>>> -------
>>>> FuseSource
>>>> Email: [hidden email]
>>>> Web: http://fusesource.com
>>>> Twitter: jstrachan
>>>> Blog: http://macstrac.blogspot.com/
>>>>
>>>> Open Source Integration
>>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: [hidden email]
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>

--
----
http://www.liquid-reality.de

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Willem.Jiang
In reply to this post by Claus Ibsen-2
On 1/25/11 12:05 AM, Claus Ibsen wrote:

> On Mon, Jan 24, 2011 at 4:59 PM, Mark Ford<[hidden email]>  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.

There are lots of class need to be updated if we wants to use the junit4
class. But I don't think we will get much benefit from it, because the
pain is much more than the gain.

It's good to see the junit4 support the junit3 classes out of box.

>
>
>> On Mon, Jan 24, 2011 at 10:33 AM, Claus Ibsen<[hidden email]>  wrote:
>>> On Mon, Jan 24, 2011 at 4:29 PM, Hadrian Zbarcea<[hidden email]>  wrote:
>>>> Agree.
>>>>
>>>> I would also drop support for junit 3.
>>>>
>>>
>>> +1
>>>


--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Willem.Jiang
In reply to this post by Christian Schneider
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<[hidden email]>
>> wrote:
>>> On Mon, Jan 24, 2011 at 4:29 PM, Hadrian Zbarcea<[hidden email]>
>>> 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<[hidden email]> wrote:
>>>>>> Hi
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 24, 2011 at 3:29 PM, Hadrian
>>>>>> Zbarcea<[hidden email]> 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: [hidden email]
>>>>>> Web: http://fusesource.com
>>>>>> Twitter: davsclaus
>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> James
>>>>> -------
>>>>> FuseSource
>>>>> Email: [hidden email]
>>>>> Web: http://fusesource.com
>>>>> Twitter: jstrachan
>>>>> Blog: http://macstrac.blogspot.com/
>>>>>
>>>>> Open Source Integration
>>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> FuseSource
>>> Email: [hidden email]
>>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

hadrian
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<[hidden email]>
>>> wrote:
>>>> On Mon, Jan 24, 2011 at 4:29 PM, Hadrian Zbarcea<[hidden email]>
>>>> 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<[hidden email]> wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 24, 2011 at 3:29 PM, Hadrian
>>>>>>> Zbarcea<[hidden email]> 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: [hidden email]
>>>>>>> Web: http://fusesource.com
>>>>>>> Twitter: davsclaus
>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> James
>>>>>> -------
>>>>>> FuseSource
>>>>>> Email: [hidden email]
>>>>>> Web: http://fusesource.com
>>>>>> Twitter: jstrachan
>>>>>> Blog: http://macstrac.blogspot.com/
>>>>>>
>>>>>> Open Source Integration
>>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> FuseSource
>>>> Email: [hidden email]
>>>> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Claus Ibsen-2
In reply to this post by Willem.Jiang
On Sun, Jan 30, 2011 at 4:19 AM, Willem Jiang <[hidden email]> 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]
>

Ah that's one of mine commits :)

Its the stupid thing with the JDK 1.5 that TimeUnit dont have MINUTES.
They stopped at SECONDS.
http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/TimeUnit.html

But added MINUTES, HOURS and DAYS to JDK1.6
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/TimeUnit.html

Maybe we should change hudson at apache to use JDK 1.6, now that we
are dropping 1.5 anyway?


> 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<[hidden email]>
>>> wrote:
>>>>
>>>> On Mon, Jan 24, 2011 at 4:29 PM, Hadrian Zbarcea<[hidden email]>
>>>> 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<[hidden email]> wrote:
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 24, 2011 at 3:29 PM, Hadrian
>>>>>>> Zbarcea<[hidden email]> 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: [hidden email]
>>>>>>> Web: http://fusesource.com
>>>>>>> Twitter: davsclaus
>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> James
>>>>>> -------
>>>>>> FuseSource
>>>>>> Email: [hidden email]
>>>>>> Web: http://fusesource.com
>>>>>> Twitter: jstrachan
>>>>>> Blog: http://macstrac.blogspot.com/
>>>>>>
>>>>>> Open Source Integration
>>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> FuseSource
>>>> Email: [hidden email]
>>>> 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
>



--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Claus Ibsen-2
Hi

I have created a wiki page for the 2.7 roadmap with the goals we have
discussed here
https://cwiki.apache.org/confluence/display/CAMEL/Camel+2.7+-+Roadmap

I took the liberty to add some goals for improved testing.



--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Dropping support for java 1.5 from camel-2.7.0 onwards

Claus Ibsen-2
Hi

I have created some tickets for the roadmap

https://issues.apache.org/jira/browse/CAMEL-3603
https://issues.apache.org/jira/browse/CAMEL-3604
https://issues.apache.org/jira/browse/CAMEL-3605




On Sun, Jan 30, 2011 at 9:30 AM, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> I have created a wiki page for the 2.7 roadmap with the goals we have
> discussed here
> https://cwiki.apache.org/confluence/display/CAMEL/Camel+2.7+-+Roadmap
>
> I took the liberty to add some goals for improved testing.
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: [hidden email]
> 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: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
12
Loading...