If we agree that camel 3.0 aims to be compatible then the refactorings
are not prossible of course.
So I propose we try to agree on a future architecture for camel core and
also assign packages to the new architectural modules. Then we can go
for the low hanging fruits and keep the rest as
On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
Hi
I think the idea is really great, but I think the timing for this is
*not* the right spot.
Why not?
And by saying that I mean the goal of Camel 3.0 is to have a short
development cycle (not like 2.0 which took a long time).
...@apache.org]
Gesendet: Dienstag, 19. Oktober 2010 13:47
An: dev@camel.apache.org
Cc: Claus Ibsen
Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel
On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
Hi
I think the idea is really great, but I think the timing
On Tue, Oct 19, 2010 at 1:47 PM, Daniel Kulp dk...@apache.org wrote:
On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
Hi
I think the idea is really great, but I think the timing for this is
*not* the right spot.
Why not?
And by saying that I mean the goal of Camel 3.0 is to
Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier
-Ursprüngliche Nachricht-
Von: Claus Ibsen [mailto:claus.ib...@gmail.com]
Gesendet: Dienstag, 19. Oktober 2010 14:22
An: dev@camel.apache.org
Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel
On Tue, Oct 19, 2010
On 18 October 2010 10:43, Schneider Christian
christian.schnei...@enbw.com wrote:
Hi all,
I will have some free time in december as I am changing my employer. So I am
planning to work a little on some architectural improvements for camel 3.0.0.
As these things are very critical to the
On 18 October 2010 18:28, Hadrian Zbarcea hzbar...@gmail.com wrote:
I changed the thread name to [discuss].
I like that idea and it's something we contemplated in the past. This will
bring back the idea of getting the dsl out of core as well.
What benefits does that have BTW? IMHO more
Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel
On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
Hi
I think the idea is really great, but I think the timing for this is
*not* the right spot.
Why not?
And by saying that I mean the goal of Camel 3.0
Meier
-Ursprüngliche Nachricht-
Von: James Strachan [mailto:james.strac...@gmail.com]
Gesendet: Dienstag, 19. Oktober 2010 14:31
An: dev@camel.apache.org
Betreff: Re: Some thoughts about the architecture of camel
So my idea would be to split camel-core into three parts:
api, builder
On 19 October 2010 13:59, Schneider Christian
christian.schnei...@enbw.com wrote:
Hi James,
it is not absolutely necessary to split the jar into three jars. More
important is to have rules that say that a component developer should only
depdend on the API part and to check that the internal
Meier
-Ursprüngliche Nachricht-
Von: James Strachan [mailto:james.strac...@gmail.com]
Gesendet: Dienstag, 19. Oktober 2010 14:31
An: dev@camel.apache.org
Betreff: Re: Some thoughts about the architecture of camel
So my idea would be to split camel-core into three parts:
api
...@gmail.com]
Gesendet: Dienstag, 19. Oktober 2010 14:22
An: dev@camel.apache.org
Betreff: Re: [DISCUSS] Some thoughts about the architecture of camel
On Tue, Oct 19, 2010 at 1:47 PM, Daniel Kulp dk...@apache.org wrote:
On Tuesday 19 October 2010 12:23:27 am Claus Ibsen wrote:
Hi
I think
: James Strachan [mailto:james.strac...@gmail.com]
Gesendet: Dienstag, 19. Oktober 2010 14:31
An: dev@camel.apache.org
Betreff: Re: Some thoughts about the architecture of camel
So my idea would be to split camel-core into three parts:
api, builder, impl
What benefits do you see for end
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier
-Ursprüngliche Nachricht-
Von: James Strachan [mailto:james.strac...@gmail.com]
Gesendet: Dienstag, 19. Oktober 2010 14:31
An: dev@camel.apache.org
Betreff: Re: Some thoughts about
If you think it's a good idea, and I agree, then 3.0 *is* the right time to do
it. It's some 5-6 months away, there's plenty of time and I expect us to get a
lot of help from the growing community.
Pushing this for 4.0 is much less realistic, we won't have another major
release in 2011. I also
On 19 October 2010 14:51, Hadrian Zbarcea hzbar...@gmail.com wrote:
The benefit if allowing developers to have their dsl that extends the camel
dsl. I get asked this question now and then (last time yesterday).
The only way to do it now is to have a separate dsl on top of the camel dsl.
Huh?
On 19 October 2010 15:06, Hadrian Zbarcea hzbar...@gmail.com wrote:
If you think it's a good idea, and I agree, then 3.0 *is* the right time to
do it. It's some 5-6 months away, there's plenty of time and I expect us to
get a lot of help from the growing community.
Pushing this for 4.0 is
I feel that we're mostly in violent agreement :). Comments inline.
Hadrian
On Oct 19, 2010, at 10:21 AM, James Strachan wrote:
On 19 October 2010 15:06, Hadrian Zbarcea hzbar...@gmail.com wrote:
If you think it's a good idea, and I agree, then 3.0 *is* the right time to
do it. It's some 5-6
[mailto:james.strac...@gmail.com]
Gesendet: Dienstag, 19. Oktober 2010 14:31
An: dev@camel.apache.org
Betreff: Re: Some thoughts about the architecture of camel
So my idea would be to split camel-core into three parts:
api, builder, impl
What benefits do you see for end users and component
Here's another thought.
We will continue to support 2.x for at least another year. Would it be less
confusing if we released 2.6 in Dec, and 2.6.x in 2011 (when needed) on jdk 1.5
and the other 2.7 and up releases on jdk 1.6 only? Give people enough heads up
to get used to the idea?
How does
Hi Hadrian,
+1
for project integrating Camel (such as ServiceMix), it will be more
flexible in that way.
Regards
JB
On 10/19/2010 06:03 PM, Hadrian Zbarcea wrote:
Here's another thought.
We will continue to support 2.x for at least another year. Would it be less
confusing if we released
I have no problem with a 3.0 release for spring and jkd upgrades. I
also like the idea that camel 3.x needs spring 3.x.
To also be able to do some breaking changes in the near future I propose
to do a 4.0 release earlier than planned. I think end of Q2 2011 could
be reasonable. We can start
I don't think the idea of 2 major releases in a year will fly. I am personally
against it until somebody convinces me otherwise.
I agree as well, that camel should move to spring 3.0. I am not convinced that
it absolutely implies a major release of camel (3.0). At this time I don't have
a
I think I used runtime in the wrong context. What I meant is that you
only need the builders when you set up a route. Then while it runs you
don´t need it anymore.
A component implementation should have no knowledge about the dsl that
created it. The advantage is then that the dsl can be
. Oktober 2010 14:31
An: dev@camel.apache.org
Betreff: Re: Some thoughts about the architecture of camel
So my idea would be to split camel-core into three parts:
api, builder, impl
What benefits do you see for end users and component developers having
to depend on at least 3 jars rather than one
Hi all,
I will have some free time in december as I am changing my employer. So I am
planning to work a little on some architectural improvements for camel 3.0.0.
As these things are very critical to the stability of camel I would like to get
feedback before I start any substantial work.
As
I changed the thread name to [discuss].
I like that idea and it's something we contemplated in the past. This will
bring back the idea of getting the dsl out of core as well.
What I'd propose Christian is to add your proposal to the roadmap [1]. I will
do the same for the dsl idea. There at
Hi
I think the idea is really great, but I think the timing for this is
*not* the right spot.
And by saying that I mean the goal of Camel 3.0 is to have a short
development cycle (not like 2.0 which took a long time).
And as a minimum (IMHO):
- To upgrade to JDK 1.6+,
- Spring 3.0+,
- To
Could you post a LOW HANGING FRUIT
Page that us mortals could start hitting?
On Oct 18, 2010, at 10:23 PM, Claus Ibsen wrote:
Hi
I think the idea is really great, but I think the timing for this is
*not* the right spot.
And by saying that I mean the goal of Camel 3.0 is to have a short
Since you did not get your Coffee :)
Would you mind putting the hindrances up to the mere mortals?
On Oct 18, 2010, at 10:23 PM, Claus Ibsen wrote:
Hi
I think the idea is really great, but I think the timing for this is
*not* the right spot.
And by saying that I mean the goal of Camel
On Tue, Oct 19, 2010 at 6:40 AM, Johan Edstrom seij...@gmail.com wrote:
Since you did not get your Coffee :)
Would you mind putting the hindrances up to the mere mortals?
What do you mean?
On Oct 18, 2010, at 10:23 PM, Claus Ibsen wrote:
Hi
I think the idea is really great, but I think
How do we help you?
On Oct 18, 2010, at 10:42 PM, Claus Ibsen wrote:
On Tue, Oct 19, 2010 at 6:40 AM, Johan Edstrom seij...@gmail.com wrote:
Since you did not get your Coffee :)
Would you mind putting the hindrances up to the mere mortals?
What do you mean?
On Oct 18, 2010, at 10:23
+1 for being fully backwards compatible. I've many projects running on
Camel 2.x and would like to benefit from Camel 3.x features without
doing any (bigger) changes.
+1 for making a bigger refactoring when going for a more idiomatic Scala
(DSL) support (with more idiomatic I mean more
On Tue, Oct 19, 2010 at 6:58 AM, Martin Krasser krass...@googlemail.com wrote:
+1 for being fully backwards compatible. I've many projects running on
Camel 2.x and would like to benefit from Camel 3.x features without doing
any (bigger) changes.
+1 for making a bigger refactoring when going
34 matches
Mail list logo
