camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maruan Sahyoun <>
Subject Re: [Camel 3 discussion] Components releases
Date Wed, 20 Feb 2013 08:11:21 GMT

Apache Camel is the victim of it's own success here. It's easy to build new components and
people are encouraged to do so. This leads to the large amount of components available and
their number will grow.

IMHO the focus should be on
o a stable, thin core. 
o a good component model
o some components maintained and released together with core
o a 'component marketplace' where other components are available

E.g. is camel-fop really essential to a large audience? Should it be maintained as part of
a core effort? We are willing to add to CAMEL-3552 (pdf component) but is this interesting
to many? Will this be a component which needs to be released and maintained regulary? If I
contribute such a component who is responsible for its further maintenance?

Maybe a look at projects like jQuery, Wordpress and many others shows how this can be done

This would help to focus on a good foundation, a basic set of components and a solid documentation
and samples for how to extend these. And a community driven set of components to add. Apache
Camel could provide the infrastructure for these or services like GitHub can be used maybe
in a similar manner jQuery does it. "Giving" up some of the components will benefit all of
us as this will free the time needed for doing core development and quicker releases if there
is something needed and/or broken in core.

Kind regards and many thanks for a great software foundation.

Maruan Sahyoun

Am 20.02.2013 um 08:09 schrieb Christian Schneider <>:

> 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 votes.
> 2. We need to support each release of a component for a certain time and make sure it
is compatible to camel core and other components in various releases.
> So a support request may read like: I am using camel-core 3.0.1 with camel-jms 2.5.4
and camel-jetty 3.2.2 but sometimes get exception xy. This is quite hard to support.
> Compare this to people who now say I am using camel 2.2.10 with camel-jms and camel-jetty.
Even my proposal would make support a lot harder.
> I think it makes sense to have minor releases every let´s say 3 months and bugfix releases
for each supported minor release also about every 1-3 months. So if we support a minor release
for a year
> it means we have about 4 minor releases to support in parallel.
> If we would theoretically release every component every 3 months or even faster it would
mean we have a gigantic number of branches and version combinations to support. This is not
manageable in my opinion.
> Christian
> Am 19.02.2013 23:21, schrieb Henryk Konsek:
>> 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 still need to wait for core to be released if they want the
>> latest version of the component. The main issue I try to address is to
>> give the users faster access the to the released components without
>> waiting for the core release.
>> Best regards.
> -- 
> Christian Schneider
> Open Source Architect
> Talend Application Integration Division

View raw message