cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans ...@domek.be>
Subject Re: Versioning of blocks
Date Mon, 09 Jan 2006 12:31:08 GMT

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


Mime
View raw message