Yep, there is no going back now. I am adding the post on the camel site and the
release notes.
Hadrian
On Feb 8, 2011, at 1:58 AM, Claus Ibsen wrote:
> Hi
>
> Now the major changes has been implemented (first 3 items from roadmap)
> http://camel.apache.org/camel-27-roadmap.html
>
> I think we
Hi
Now the major changes has been implemented (first 3 items from roadmap)
http://camel.apache.org/camel-27-roadmap.html
I think we should post a note on the 2.6 release notes about the
change moving forward.
Also we should consider adding a news post on the camel website as well.
eg about jdk 1
I agree, you're absolutely right Claus. Easiest it to do it in a few smaller
steps.
Cheers,
Hadrian
On Feb 5, 2011, at 3:08 AM, Claus Ibsen wrote:
> On Sat, Feb 5, 2011 at 3:40 AM, Hadrian Zbarcea wrote:
>> CAMEL-3603 is done. What's next? Dropping Junit 3?
>>
>
> That's great Hadrian.
>
>
Hi
I have upgraded to Spring 3.0 as minimum now.
--
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/
On Sat, Feb 5, 2011 at 3:40 AM, Hadrian Zbarcea wrote:
> CAMEL-3603 is done. What's next? Dropping Junit 3?
>
That's great Hadrian.
There is a tiny bit Java code which can be migrated to Java 6, for
example IOException now accepts a nested exception so we dont need to
use IOHelper for that.
I
CAMEL-3603 is done. What's next? Dropping Junit 3?
Hadrian
On Feb 4, 2011, at 2:54 AM, Claus Ibsen wrote:
> Hi
>
> Camel 2.7 roadmap
> http://camel.apache.org/camel-27-roadmap.html
>
> The switching to slf4j logging is now complete on trunk.
>
> Are we ready for the next step? To drop JDK 1.5
Hi
Camel 2.7 roadmap
http://camel.apache.org/camel-27-roadmap.html
The switching to slf4j logging is now complete on trunk.
Are we ready for the next step? To drop JDK 1.5?
https://issues.apache.org/jira/browse/CAMEL-3603
When we get started on this, there is no turning back.
--
Claus Ibs
On 1/30/11 1:16 PM, Hadrian Zbarcea wrote:
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 f
On Mon, Jan 31, 2011 at 11:25 AM, Christian Müller
wrote:
> Droping Spring 2.x also means:
> - removing the features file for Spring 2?
> - removing the camel-itest-spring-2.0 module?
>
> Should we put this to the issue?
>
Yeah please comment on the JIRA tickets.
There is also code in camel-jms
Droping Spring 2.x also means:
- removing the features file for Spring 2?
- removing the camel-itest-spring-2.0 module?
Should we put this to the issue?
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 wrote:
> Hi
>
> I have created a wiki page for the 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: cib...@fusesource.com
Web
On Sun, Jan 30, 2011 at 4:19 AM, 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]
>
Ah that's one of mine commits :)
Its the stupid thing with the JDK 1.5 that TimeUnit dont have MINUTES.
They stop
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 2
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/
On 1/25/11 12:05 AM, Claus Ibsen wrote:
On Mon, Jan 24, 2011 at 4:59 PM, Mark Ford 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 backw
+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
On Mon, Jan 24, 2011 at 4:59 PM, Mark Ford 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 annota
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 mi
+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
On Mon, Jan 24, 2011 at 4:29 PM, Hadrian Zbarcea 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
Spr
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
erformance
http://www.slf4j.org/faq.html#logging_performance
> Christian
>
>
> -Ursprüngliche Nachricht-
> Von: Claus Ibsen [mailto:claus.ib...@gmail.com]
> Gesendet: Montag, 24. Januar 2011 15:49
> An: dev@camel.apache.org
> Betreff: Re: [DISCUSS] Dropping support for j
+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 wrote:
> Hi
>
>
>
> On Mon, J
On Mon, Jan 24, 2011 at 3: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 whi
Hi
On Mon, Jan 24, 2011 at 3: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
+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
27 matches
Mail list logo
