> > >> 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 > incorrectly. >
Well that's a risk someone can't deny. But aren't there situations today where people might not be able to update camel? > 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. No need to stop working on select components and either release them together with core or put them in the marketplace. > > 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? You are right - components are what people are interested in. But the number of components will not shrink if there is no decision to abandon some of them. > > 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. It's not about dropping support. It's about handling it differently. And again - if my impression of lack of time, long release cycles etc. I got from the discussions was wrong then there might not be a need for a different approach. > > [1] http://grails.org/plugins > > -- > Henryk Konsek > http://henryk-konsek.blogspot.com
