Hi Maruan,
I agree with the goals you defined.
A stable and thin core would be great. The problem is that core is not
really thin at the moment. So I think we need to do at least one release
with breaking changes before we can then have a stable and thin core.
The idea of a component marketplace sounds great. What we need to make
it work is a community for the components outside camel. The apache
processes are not very suitable for these separate components.
Maybe ops4j could be a choice. After choosing a community we would then
have to decide which components to keep in camel and which to move to
the marketplace. I guess this could be done with a poll by selecting the
most used and wanted components to stay in camel. Github as a place to
store the components is good but we need a community that makes sure
legal and licensing concerns are addressed. Github does not care about this.
Last but not least this community has to provide a defined way to get
these components into maven central so it is as easy as now to use them.
Christian
Am 20.02.2013 09:11, schrieb Maruan Sahyoun:
Hi,
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 successfully.
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 <ch...@die-schneider.net>:
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
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
