Daniel Fagerstrom wrote: > --- 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. > > The only importance of the "global" directory structure of the SVN is > that if we have a number of projects that many people in the community > are likely to want to have checked out, it is more practical to have > these in the same SVN folder (trunk) so that you just can check out the > whole folder. For the trunk we can also have a common POM that builds > all the projects in the trunk. > > A "higher" level POM have two different responsibilities: it has a list > of sub projects that it build recursively and it contain common > definitions for the sub projects. Sub projects can refer to the "higher" > level POM as parent POM. IIUC the subprojects only reuse the > commondefinitions and not the list of sibling projects. To keep sub > projects as independent as possible, the parent POM should only contain > definitions that are likely to be stable over time, like repository > references. It should be mentioned though that the parent POMs also are > versioned and put in the repository so a project in a sub folder can > referer to an earlier version of the parent POM if necessary. > > But building all projects at once will be much less important with M2 as > all sub projects can be build independently and use dependencies from > the snapshot repository. > > --- 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. > > 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. > > /Daniel >
*very* well put. I will add this to our M10N docs, this is important conceptual stuff everybody should be in line with. Thanks! Jorg
