camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henryk Konsek <>
Subject Re: [Camel 3 discussion] Components releases
Date Wed, 20 Feb 2013 13:53:11 GMT
> Christian:
> 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.

CR-01 release of all components would be performed together with core.
Component releases higher than CR-01 would be performed seldom,
usually on explicit user request. In practice there will be only
several of additional CRs between core releases.

> Christian:
> 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.

No, it can't look like this, as my CR qualifier applies only to the
certain version of core release.
You example would look like: I am using camel-core-3.0.1 with
camel-jms-3.0.1-CR-01 and camel-jetty-3.0.1-CR-02 but sometimes get
exception xy.
And this is quite easy to support as only jetty component has been
additionally released.

Using Maven version qualifiers is not the same as using totally
independent versioning for each component, as qualifier is bound to
the particular release version of the core.

> Maruan:
> you nailed it. The idea of the marketplace is to give up responsibility. Apache Camel
is responsible for the
> foundation (software, infrastructure, procedures). The component developer has
> responsibility for the component.

If we follow this path, we will end up with bare core and marketplace
full of lousy components. Take a look at Grails plugin repository [1].
There are hundreds of them, but half of them don't work well with the
latest Grails. Grails developers cut the core release and don't care
about the plugins. This approach leads to situations when user cannot
upgrade core Grails because plugins stop to work, or even worse, work

The part of success of Camel is that it supports almost every
technology and supports it well. Our components are well tested
against the core. You can safely update Camel core and don't mind that
components will go crazy.

Our great and stable components repository is something that makes us
really competitive comparing to Spring Integration or Mule. They got
EIP, JMS, WebServices and e-mail support as well. In my humble opinion
end users don't care about the polished core. What they care about is
the stable, polished and wide pallet of components they can use out of
the box. End users get excited when they see the impressive list of
components we support out of the box. If we drop our components
portfolio, we would be no better than Spring Integration. Our core
could be designed better, but will user care about it?

Is there really a problem with components maintenance and releases?
Majority of them doesn't change. They don't block the releases. In my
opinion we should focus on speeding up the delivery of the components
instead of dropping support for the important part of our success.


Henryk Konsek

View raw message