+1
Guillaume Nodet 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
* ...
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.
Thoughts, ideas ?
