Daniel Fagerstrom wrote: > > You got it right. > Yuppie, thanks Daniel!
Ok, I think this can work and - as you already said - we should try this out and see what happens. Sometimes I need a little bit more time to understand everything :) > --- o0o --- > > With M2 the directory structure of the SVN repository have much less > importance as all dependencies are handles through POMs. You can as an > example just check out trunk/cocoon-session-fw/cocoon-session-fw-sample > and work on it independently. It will use the most current snapshots of > cocoon-core and cocoon-session-fw from our snapshot repository. Yes, and this is one of the great benefits. You can just check out the block you want to work on and that's it. > <SNIP/> > > --- o0o --- > > For the scenario you mentioned in an earlier mail where some but not all > blocks in the trunk is compatible with the cocoon-core in trunk, only > the ones that are compatible with core and compiles together are listed > in the module list in the trunk level POM. The blocks that isn't > compatible with the cocoon-core in trunk, just refer to an earlier > version of cocoon-core in their dependency list, and possibly an earlier > version of the parent POM. > Ok, yepp and as soon as the block works with the current version of trunk it will be added to the main pom again. Fine. > Now, this kind of problems mainly depend on the fact that we have weak > contracts between blocks and between core and the rest of the blocks. > And also because the core is far to "fat". With M2 it is much easier to > handle build system and dependency issues. So we can start to split the > core into much smaller parts and strenghten the contracts. By doing > this, most of the issues with complicated and unclear interdependencies > will disapear. > Hopefully :) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
