That makes perfect sense. However i'm a bit worried about the bundles, because lots of different components will require different bundles. As soon as we want to integrate a camel component, we will need to make bundles for its dependencies. I don't really see why we should release the runtime to add such a bundle (which btw would not be included). So while I agree on a more coarse grained separation, I would split the bundles from the remaining of the code (it does not really involve any code, just a pom) so that we can easily release bundles separatly, as once a bundle is released, it will rarely require further releases. Wdyt ?
On Dec 5, 2007 10:11 AM, James Strachan <[EMAIL PROTECTED]> wrote: > On 04/12/2007, Bruce Snyder <[EMAIL PROTECTED]> wrote: > > On Dec 4, 2007 3:19 PM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > I've finished writing the wiki page wrt to the smx4 subtree at > > > http://cwiki.apache.org/confluence/display/SMX4/SVN+repo > > > > > > Feedback welcome. > > > > Regarding the two choices for the SMX 4 SVN repo, I'm starting to ask > > myself the same question I always do when something starts to become a > > little more complex than it feels like it should be: Is there an > > easier way? IOW, what's the easiest route to take here? IMO, it's > > probably more straightforward to give each component it's own > > branches/tags/trunk dir. We don't want to cram everything into a > > single dir tree and hide the complexities of building in the POMs. > > Releases are a major bit of work to complete (and a PITA :); so I'm a > little nervous about having too many separate releases, trunks and > different branches. > > So I'm wondering about trying to minimise releases into these parts... > > (i) parent, core bundles (for jaxb and stuff) and runtime > (ii) nmr & jbi support > (iii) components, tools and the full SMX distro > > Then (ii) depends on (i) and (iii) depends on (i) and (ii) (though a > component may only depend on (i) I guess). > > In the early days I see (i) and (ii) releasing frequently, but (i) > should become stable & not need many releases soon, as will (ii) some > time after that and then eventually we'll mostly put our efforts into > releasing (iii). > > Eventually the main reason for releasing (i) and (ii) will mostly be > minor patches and changes to core dependencies like spring versions > etc. > > Hopefully this split will help make releasing easier (less to build & > test). We could always split things up or aggregate them together > further down the line if we think it makes sense - but given the large > amount of effort & documentation required for each release I'd rather > us have slightly less released parts than too many. > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
