On 1 September 2011 02:01, Hadrian Zbarcea <hzbar...@gmail.com> wrote: > Personally, I don't think we need a big jar. My understanding is that > Christian is looking for ways to *improve* modularity and reduce > dependencies.
But he was suggesting making camel-core bigger & adding in more dependencies by shoving camel-core-xml in there :). For someone so keen to try enforce rules, he's broke his modularity rule already :) > I am not a big fan of big fat jars (and my understanding is > that that is not what Christian proposed). Modularity is a key aspect of > Camel. Agreed. Though having a bigger jar as an option (say camel-core + camel-core-xml + camel-spring) could be handy for folks who use camel + spring together alot. Its less of an issue in the osgi world with features though. > Anyway, I'd suggest leaving camel-core-xml the way it is and tackle that in > 3.0. Agreed. We should be careful to keep 2.x of Camel nice and stable from an API perspective; but we can experiment in 3.x for sure. I'm also not sure how much smaller we can really get camel-core; since out of the box you'd assume camel can work with JMX, beans, files & implement the patterns and have the model in there. Shaving off 20-100k doesn't seem that big a deal IMHO; the bean / file stuff isn't that big. -- James ------- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan, fusenews Blog: http://macstrac.blogspot.com/ Open Source Integration and Messaging
