Hi Christian,
what you did is similar to what I did when I moved classes. It is a way
to stay compatible while moving some classes.
The problem is that the kind of refactorings you can do with this
aproach are quite limited.
What I had in mind is a much bigger change.
Basically the idea is t
I am -1 for separate component releases. There are two problems:
1. Each component release needs a vote. So with the 100+ components we
would have 100 votes instead of one vote for a camel release.
Of course it is less in practice as not every component is released
every time but still a lot of
It's hard to track all the version of camel-component and it will make the
release process every complex, if we don't release it with the core. So I
cannot agree with this proposal.
As you know In ServiceMix we have lots components which have not direct
dependency with the core, so we break t
And actually the core should not even change that often. And the api
should change even less often. Ideally we would only have major api
releases (ideally, that is).
Hopefully we'll find a better solution for our release process.
Cheers,
Hadrian
On 02/19/2013 05:21 PM, Henryk Konsek wrote:
Except this is not a vote and hence not a veto :).
Claus expressed that his views are different, no biggie.
Cheers,
Hadrian
On 02/19/2013 02:51 PM, James Carman wrote:
A veto must be accompanied by a justification in order for it to stand:
http://www.apache.org/foundation/voting.html
On Feb 1
Hi Henry,
>From what I understood, you were suggesting a different versioning model
for components at the POM level.
My suggestion was to keep the current POM versioning model, but just create
a "component hotfix" repository where we can publish "tags" of components
upon demand. To continue with
Christian, Claus, others...
could you please have a look at the following commit:
https://github.com/muellerc/camel/commit/fd9bb64586c1d082e4169cf08831da9c2b6afccb
This is my understanding of bridging the existing code to the new one. Do
we have the same understanding?
Of course I have to change t
Hi Christian,
> How about a simpler model?
> A component could specify the minimum camel core or better api in the future
> it needs.
> For example:
> camel-jms 3.0 -> camel-core 3.0
> camel-jms 3.1 -> camel-core 3.0
Unfortunately this approach doesn't address the problem that component
users sti
Hi Raul,
> So my proposal is to create a "hotfix" procedure within the Camel
> community. If a Committer feels they have just committed an important fix
> which cannot wait for the next Camel release, they can push a hotfix
> release to Maven Central, e.g. camel-jms-3.2.1-HF-01.
> Performing such
This sounds like it could be pretty difficult to manage.
How about a simpler model?
A component could specify the minimum camel core or better api in the
future it needs.
For example:
camel-jms 3.0 -> camel-core 3.0
camel-jms 3.1 -> camel-core 3.0
For OSGi dependencies this would make the pac
I also thought about a future routing engine some time ago and I think
your ideas make sense.
When we remove the possibility of routing steps to simply call
processors then we have to reflect the possible
branches in the model itself. So it is pretty natural to introduce
something like a Routing
The value proposition is awesome. But it's way too complex for a community
to manage up to 130+ independent lifecycles.
On the other hand, as a user, I'd love to upgrade my Camel JMS component to
a newer release without upgrading Camel as a whole. To pull in bug fixes, a
particularly interesting f
It's a big undertaking but I feel we're at the right moment to redesign the
core of Camel, make it leaner and pull in the routing concepts into the API
model itself. It's basically now or never.
One of the cornerstones of what I have in mind is to diversify the concept
of the Processor into its se
This was the today's discussion on IRC (irc://irc.codehaus.org/camel). Feel
free to join the next time and/or comment on the today's discussed items.
The next one is scheduled for 02/26/2013 7:00PM - 8:00PM CET. Feel free to
join and express your ideas/needs/wishes/...
[19:00:14] let's DISCUS
I'm interested in this too! I'm here to help.
On Feb 19, 2013, at 3:44 PM, Christian Müller
wrote:
> Hadrian,
>
> did you found time to work on the new Camel components test kit?
> Should we plan a coding session in Portland?
>
> Best,
> Christian
>
> On Tue, Feb 19, 2013 at 8:34 PM, Hadria
Hadrian,
did you found time to work on the new Camel components test kit?
Should we plan a coding session in Portland?
Best,
Christian
On Tue, Feb 19, 2013 at 8:34 PM, Hadrian Zbarcea wrote:
> Comments inline.
> Cheers,
> Hadrian
>
>
> On 02/19/2013 01:09 PM, Claus Ibsen wrote:
>
>> On Tue, Fe
+1
Sent from a mobile device
Am 19.02.2013 01:21 schrieb "Raul Kripalani" :
> Hello team,
>
> We use a recursive model in our routing engine to chain processors with one
> another to process exchanges.
>
> This results in lengthy stacktraces and increased memory usage due to local
> variable rete
Thanks for the update!
Sent from a mobile device
Am 19.02.2013 06:48 schrieb "Hadrian Zbarcea" :
> The full tests are still running, looks like I'll only finish the release
> tomorrow.
> Hadrian
>
> On 02/18/2013 08:43 AM, Hadrian Zbarcea wrote:
>
>> The cxf features 2.6.6.1 are now released. I'l
A veto must be accompanied by a justification in order for it to stand:
http://www.apache.org/foundation/voting.html
On Feb 19, 2013, at 1:13 PM, Claus Ibsen wrote:
> I am -1 on this.
>
> On Tue, Feb 19, 2013 at 8:16 AM, Henryk Konsek wrote:
>> Hi,
>>
>> Unfortunately I won't be able to join
Comments inline.
Cheers,
Hadrian
On 02/19/2013 01:09 PM, Claus Ibsen wrote:
On Tue, Feb 19, 2013 at 11:04 AM, Christian Schneider
wrote:
Hi Claus,
do you think it is possible to refactor camel core in this way (to
implement a real routing engine)? After the refactorings I already did I
am not
> I am -1 on this.
Would you mind telling me any particular reason behind this -1? I'm
just curious why this idea is so terribly bad :) .
--
Henryk Konsek
http://henryk-konsek.blogspot.com
I am -1 on this.
On Tue, Feb 19, 2013 at 8:16 AM, Henryk Konsek wrote:
> Hi,
>
> Unfortunately I won't be able to join the IRC session today as I need
> to hire myself as a babysitter this evening. However I would like to
> discuss some subject that come up recently [1]. One on the issues
> discu
On Tue, Feb 19, 2013 at 11:04 AM, Christian Schneider
wrote:
> Hi Claus,
>
> do you think it is possible to refactor camel core in this way (to
> implement a real routing engine)? After the refactorings I already did I
> am not sure it would work.
>
Yes it is possible. The main switch is to use a
Hi folks,
at last I managed to set up a Wiki page for discussing Camel 3 Message
Store. Here is is:
https://cwiki.apache.org/confluence/display/CAMEL/Camel+3.0+-+Message+Store
You are invited add, comment, criticize etc. The more thoughts and
ideas we get, the more likely it is to cover the user
Github user cabeaulac closed the pull request at:
https://github.com/apache/camel/pull/11
Hi
We should close down on a Camel 2.11 release.
What we are waiting for is a Karaf 2.3.1 release so Camel 2.11 can run on Karaf.
So when Karaf 2.3.1 is out, it would be good to for Camel trunk code
to be in shape for being released.
Camel 2.10 is from July last year, so its about time we get t
I put together a fix for CAMEL-2624. All 90+ unit tests pass. This ticket will
open a whole new area of functionality for Mina in Camel.
https://issues.apache.org/jira/browse/CAMEL-2624
The Github pull request is located here:
https://github.com/apache/camel/pull/11
Claus didn't like passing the
> However the main problem I see is lack of organization in camel codebase.
> Camel has gazilion of similar components which doesn't share anything except
> core dependency.
Actually I must disagree as in my humble opinion organization of Camel
code and it's internal reusability has nothing to do
Hi Claus,
do you think it is possible to refactor camel core in this way (to
implement a real routing engine)? After the refactorings I already did I
am not sure it would work.
Another aproach instead of refactoring would be to first define a new
really slim API for components and implement it us
I'll create a section in the evening with references to the associated
ideas.
How are we handling the prototyping of ideas? Collaborate on code, reviews,
(virtual) pair programming if we have a joint championship, etc. SVN is
inflexible, but GitHub has the social element we need.
Working on branc
I know there are some people who are able to support scala in Camel
repositories. However the main problem I see is lack of organization in camel
codebase. Camel has gazilion of similar components which doesn't share anything
except core dependency. There is lack of any abstractions for queueing
On Tue, Feb 19, 2013 at 8:20 AM, Christian Schneider
wrote:
> +1
>
> I think one of the main things camel is missing is a routing engine.
> Like you wrote, currently each processor calls the next. Aspects like
> asynchronous behaviour, transaction and security are also
> implemented as processors.
Raul you have huge
+1
from me on this idea.
Basically I was thinking about idea of "logical" modules for Camel 3.0 which
could modify routing chain, property configurations. Overall purpose is to get
rid from core all magic which was built around
PropertiesComponent/TraceInterceptor and so on
33 matches
Mail list logo
