Is there any need for a single root pom without any real version number, so that all our projects inherit from it ? It would contain the committers list, mailing lists, etc... I guess we can easily duplicate it in the subtrees, but duplication is usually a bad idea.
Anyway, I'll start reorganizing the svn tree monday unless someone has some objections. On Dec 5, 2007 7:07 PM, James Strachan <[EMAIL PROTECTED]> wrote: > On 05/12/2007, Bruce Snyder <[EMAIL PROTECTED]> wrote: > > On Dec 5, 2007 3:20 AM, James Strachan <[EMAIL PROTECTED]> wrote: > > > 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? > > > > This looks to be getting pretty complex. > > Having 3 releases - how much simpler could you get? > > > > Any way to simplify it and > > make it more straightforward? Can't a bundle list it's dependencies > > and versions to make all these inter-dependencies from the runtime and > > the core bundles disappear? > > The bundles we're talking about are just maven projects with a > pom.xml. The pom lists its dependencies. > > > > E.g., if it comes time to release a new > > version of the Camel bundle, can't that bundle explicitly list its > > dependencies so there is no clash with anything in the runtime? > > It does. > > We're really just talking about the little maven projects which make > an OSGi bundle wrapping a regular jar. e.g. > > http://svn.apache.org/repos/asf/servicemix/branches/servicemix-4.0/bundles/ > > And I repeat - Camel is bad example as its already bundles. So think > things like the jaxb-api jars. > > I'm just suggesting, the bundles required by the runtime should move > there; any bundles required by components go there, any bundles > required by JBI/NMR go there. i.e. keep the bundles with the most > suitable release (runtime, jbi/nmr or components). > > Then things are actually nice and simple; we have 3 releases (runtime, > jbi/nmr and components) and we just release the things that really > need to be released; and if a bundle needs to be re-released (e.g. a > new jaxb-api jar) we can often just do 1 release - rather than, say, a > bundle release first then a runtime release second. > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
