[DAISY] Updated: M10N

[daisy]

A document has been updated:

http://cocoon.zones.apache.org/daisy/documentation/756.html

Document ID: 756
Branch: main
Language: default
Name: M10N (previously Cocoon's Mavenization)
Document Type: Cocoon Document (unchanged)
Updated on: 1/11/06 3:09:16 PM
Updated by: Jorg Heymans

A new version has been created, state: publish

Parts
=====
Content
-------
This part has been updated.
Mime type: text/xml (unchanged)
File name:  (unchanged)
Size: 9264 bytes (previous version: 6341 bytes)
Content diff:
(61 equal lines skipped)
    
    <h2>The repository structure</h2>
    
+++ <p>The repository structure was flattened from 2.1 to allow for better
+++ integration with maven.</p>
+++ 
+++ <p>Daniel Fagerstrom summarized nicely why this structure will work for us 
:</p>
+++ 
+++ <pre>&gt; With M2 the directory structure of the SVN repository have much 
less
+++ &gt; importance as all dependencies are handles through POMs. You can as an
+++ &gt; example just check out trunk/cocoon-session-fw/cocoon-session-fw-sample
+++ &gt; and work on it independently. It will use the most current snapshots of
+++ &gt; cocoon-core and cocoon-session-fw from our snapshot repository.
+++ &gt; 
+++ &gt; The only importance of the "global" directory structure of the SVN is
+++ &gt; that if we have a number of projects that many people in the community
+++ &gt; are likely to want to have checked out, it is more practical to have
+++ &gt; these in the same SVN folder (trunk) so that you just can check out the
+++ &gt; whole folder. For the trunk we can also have a common POM that builds
+++ &gt; all the projects in the trunk.
+++ &gt; 
+++ &gt; A "higher" level POM have two different responsibilities: it has a list
+++ &gt; of sub projects that it build recursively and it contain common
+++ &gt; definitions for the sub projects. Sub projects can refer to the 
"higher"
+++ &gt; level POM as parent POM. IIUC the subprojects only reuse the
+++ &gt; commondefinitions and not the list of sibling projects. To keep sub
+++ &gt; projects as independent as possible, the parent POM should only contain
+++ &gt; definitions that are likely to be stable over time, like repository
+++ &gt; references. It should be mentioned though that the parent POMs also are
+++ &gt; versioned and put in the repository so a project in a sub folder can
+++ &gt; referer to an earlier version of the parent POM if necessary.
+++ &gt; 
+++ &gt; But building all projects at once will be much less important with M2 
as
+++ &gt; all sub projects can be build independently and use dependencies from
+++ &gt; the snapshot repository.
+++ &gt; 
+++ &gt;                        --- o0o ---
+++ &gt; 
+++ &gt; For the scenario you mentioned in an earlier mail where some but not 
all
+++ &gt; blocks in the trunk is compatible with the cocoon-core in trunk, only
+++ &gt; the ones that are compatible with core and compiles together are listed
+++ &gt; in the module list in the trunk level POM. The blocks that isn't
+++ &gt; compatible with the cocoon-core in trunk, just refer to an earlier
+++ &gt; version of cocoon-core in their dependency list, and possibly an 
earlier
+++ &gt; version of the parent POM.
+++ &gt; 
+++ &gt; Now, this kind of problems mainly depend on the fact that we have weak
+++ &gt; contracts between blocks and between core and the rest of the blocks.
+++ &gt; And also because the core is far to "fat". With M2 it is much easier to
+++ &gt; handle build system and dependency issues. So we can start to split the
+++ &gt; core into much smaller parts and strenghten the contracts. By doing
+++ &gt; this, most of the issues with complicated and unclear interdependencies
+++ &gt; will disapear.</pre>
+++ 
    <h2>How to do a full cocoon build</h2>
    
    <p><tt>$mvn -Dmaven.test.skip=true install</tt></p>
(27 equal lines skipped)
    
    <ul>
    <li>Use the archetype plugin to create a quick template block structure in 
the
--- repo root  (assuming the name of the block you want to create is 
+++ repo root (assuming the name of the block you want to create is
    "cocoon-core".<tt><br/>
    <br/>
    $mvn archetype:create -DgroupId=org.apache.cocoon 
-DartifactId=cocoon-core<br/>
(84 equal lines skipped)


Fields
======
no changes

Links
=====
no changes

Custom Fields
=============
no changes

Collections
===========
no changes