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.
> 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?
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?
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/
