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 >
