It seems there's no major objections, so I will start moving the svn tree for servicemix 3 and servicemix 4 on monday, though I won't touch the smx4 tree now (just move it). We can talk about the exact smx4 tree at a later time. If there are any objections please speak now!
On Nov 28, 2007 9:43 PM, 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 > * ... > > 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/ -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
