On 05/12/2007, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > That makes perfect sense. However i'm a bit worried about the bundles, > because lots of different components will require different bundles. As > soon as we want to integrate a camel component, we will need to make bundles > for its dependencies. I don't really see why we should release the runtime > to add such a bundle (which btw would not be included). So while I agree on > a more coarse grained separation, I would split the bundles from the > remaining of the code (it does not really involve any code, just a pom) so > that we can easily release bundles separatly, as once a bundle is released, > it will rarely require further releases. Wdyt ?
Yeah I guess. Another option could be to split the bundles, those required by the runtime go in the runtime release (so mostly things like JAXB and spring dependent stuff). Then have the remaining bundles required by the components in the components release? So if, say, a new camel release comes out, you'd only need to release the components module for the new camel bundle and the camel component? (Rather than release the bundles first, then once that release is up on the public site, release the components - causing a delay of a week or two per component release). (Bad example I guess as all the jars in camel are bundles already, but I totally take your point :) Given the simplicity of the bundle stuff; am tempted to just hide 'em where they make the most sense to go (i.e .with their core dependency - runtime, jbi/nmr or components)? At least to start with - we can tinker later on if we find bundles that don't fit nicely? -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
