On Nov 29, 2007 4:58 AM, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> On 11/28/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > I'm think about reorganizing the svn tree to be more modular.
> > Something like:
> >
> > https://svn.apache.org/repos/asf/servicemix
> > * m2-repo
> > * sandbox
> > * scripts
> > * site
> > * smx3
> > ** branches
> > ** tags
> > ** trunk
> > * smx4
> > ** ...
> >
> > This will be usefull so that we can have two trunks: one for smx3 and
> > another for smx4.
> > Basically, it's just about moving trunk/tags/branches into a subdir for
> > servicemix 3 related work
> > and create a new area for servicemix 4 work.
> >
> > I'm thinking we want to make servicemix 4 more modular and release the
> > runtime asap, then releasing bits when they are ready (I'm thinking
> about
> > the JBI layer first, etc...). The next step is to build a usable
> assembly /
> > binary distribution which will contain all the modules at a given time.
> >
> > In that direction, we could have a "bundles" subtree in smx4 which would
> > contain OSGified jars that other modules would need. One of the
> advantages
> > is that we can release things more often, depends on less snapshots and
> have
> > a build time much faster when you are working on a given module (when
> > working on the JBI layer, there's no real need to build openejb or cxf
> > bundles, etc..)
> > So the smx4 subtree would look like
> >
> > smx4
> > * pom
> > ** branches
> > ** tags
> > ** trunk
> > * bundles
> > ** branches
> > ** tags
> > ** trunk
> > * runtime
> > ** branches
> > ** tags
> > ** trunk
> > * jbi
> > ** branches
> > ** tags
> > ** trunk
> > * ...
>
> +1
>
> At a high level this looks much more manageable. In SMX 4, I
> understand that the bundles, jbi and runtime dirs will each have their
> own branches, tags and trunk dirs. But what are the branches, tags and
> trunk dirs beneath the root pom? Will the full uber distribution live
> there? I think it shoudl have it's own dir containing its own
> branches, tags and trunk dirs.
I'm not sure if we really need the pom subtree. My idea is that we are in
need of
a root pom that all modules will inherit. It will contain basic
informations such as the mailing lists, licenses, etc... Not much really,
but we still need it.
>
>
> > Even for bundles, we should release them early and independantly as
> working
> > with snapshots is always a pain imho.
> > In addition, splitting things would avoid lenghty builds, having failing
> /
> > unstable test impacting the whole build. Of course we would still have
> a
> > module with the whole binary distribution.
> >
> > I'm thinking the main downside is that patches involving more than one
> > component would be more difficult to apply and would have to be
> splitted,
> > but i think it's worth it.
>
> At a high level, I still like this idea. But I still have some
> concerns about allowing users to fall victim to dependency hell. So
> how exactly are components going to be downloaded to run on the core
> runtime? Will there be an automatic facility for this?
I think we have to release a full distribution from time to time so that
users can get started easily.
That said, we need to find a way of downloading and installing 'features'
easily. This will be done through the shell console, using either OBR or
pax-runner, or any other easy to use mechanism.
This means that one would type (for example)
obr/install apache-ode:1.2
and it would install everything needed.
Then we need to provide offline tools to create distribution ready to use
for a given environmnent, where all the needed modules would be packaged in
a single zip.
>
> Also, on a slightly different note, the SMX 4 runtime is going to be
> based on OSGi, how will this affect the ability to embed SMX into
> another Java application? I don't imagine that folks will always want
> an OSGi container running inside of their Java app, so how will we
> work around this to still allow it to be embedded?
There are two ways of doing that: the first one is to simply embed the OSGi
runtime in the application (a web app or not). It's quite easy to do and I
do not see any problems. I see that as the easiest way because the changes
would be minimal, as you would just get rid of things like the file poller
which automatically installs bundles etc...
The other way is to just use the jars and remove all OSGi stuff. The NMR
api has no dependency on OSGi and OSGi is mostly used through spring for
wiring everything, for classloaders and for deployment. If you want to
embed ServiceMix in your app, just use spring to wire all you need together.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
> Castor - http://castor.org/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
