cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Flattening trunk
Date Mon, 26 Sep 2005 09:58:32 GMT
Niclas Hedhman wrote:

>On Sunday 25 September 2005 21:39, Daniel Fagerstrom wrote:
>>I think we should move the content of trunk/src/ to trunk/, and 
>>start considering them as separate projects (blocks).
>I would be really happy if a top-level build script (maven, ant, bash, perl, 
>whatever) is maintained for us poor souls who wouldn't know what depends on 
>what, and in which order stuff needs to be built.
That is the intention, you can see that there is a toplevel POM in the 
new M2 build. IIUC M2 POMs describe all the dependencies and the block 
POMs refers to the toplevel POM and build the needed blocks.

>Doesn't need to support 
>everything, just one sweep to compile/package each part.
>Also, in the long run, consider getting rid of the ttb structure, drop the 
>heritage from CVS and make a more direct statement;
>  main/
>  legacy2.1/
>  releases/
>  experiments/
>or something along those lines.
Agree. As your explanation is somewhat terse I expand a little bit on it.

When we discussed repository structure in Felix I propsed that we should 
follow the same structure as for Cocoon blocks with 
ttb(=trunk/tag/branch) under each bundle directory. Niclas instead propsed:

>Personally, I don't use tags and branches at all. Code that are released, are 
>copied into a proper directory named "releases", and straight after made 
>read-only. Branches are handled differently depending on whether it is an 
>"experiment" (in which case it is just copied to my laboratory) or it is 
>"maintenance" of released code, in which case I first copy the "release" into 
>a temporary area, do the changes and then create a new "release" make 
>readonly and so forth.
Which we all agreed about as it seem to be more practical. We should do 
the same for Coccon IMO. In the directory structure above we would have


or maybe with a subdirectory for blocks, not certain if I want that as 
everything is blocks anyway. All the blocks are own projects and when we 
release a block we put it in releases:


Simple and easy to understand!


View raw message