servicemix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Reorganizing the svn tree
Date Wed, 05 Dec 2007 18:07:00 GMT
On 05/12/2007, Bruce Snyder <bruce.snyder@gmail.com> wrote:
> On Dec 5, 2007 3:20 AM, James Strachan <james.strachan@gmail.com> wrote:
> > On 05/12/2007, Guillaume Nodet <gnodet@gmail.com> 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

Mime
View raw message