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 ? -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
