[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [M10N] new repo layout
From:       Vadim Gritsenko <vadim () reverycodes ! com>
Date:       2005-11-04 2:24:31
Message-ID: 436AC65F.8070508 () reverycodes ! com
[Download RAW message or body]

Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
> 
>> IIRC, we already have separated out blocks out of the core, into
>>
>>   svn:/cocoon/blocks/
>>
>> Where each block is treated as independent project, and has own 
>> tags/branches. With Cocoon 2.1.8 out this friday, several blocks will 
>> start having own tags.
> 
> The current structure with trunk/tags/branches under each block will 
> become rather unconvenient as soon as we start to relase and tag things.

I would say "unavoidable" rather than inconvenient. Where would you put block's 
tags if not under the tags, then?


> Right now you can just check out svn:/cocoon/blocks without any 
> problems, but with a number of tags for each blocks you soon get quite a 
> lot to check out, then you either need to check out each 
> blocks/<name>/trunk separately or we have to provide a directory with 
> externals to each block trunk. But that was extremely slow when we tried 
> that a while ago.

Yes. That was the known issue (iirc i myself brought this up back then), and 
back then it was recognized that svn:externals is only a temporary measure.

Having one external per block is too slow, and having one external for all 
blocks is not possible, so IMHO best way is to write simple sh/bat file for 
checking out trunks of all blocks into pre-defined directory structure. Even 
better if maven somehow can help out here... Either through standard tools or 
custom plugin...


> Read the links in 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112790057318179&w=2 for 
> description of a better way to solve it.

It essentially proposes [1] to move ttb's up one level. something like

   /trunk
     /cocoon
     /blocks
       /axis
       /forms
   /tags
     /cocoon-2.1.8
     /cocoon-axis-1.0
     /cocoon-forms-1.0
   /branches
     /cocoon-2.1
     ...

(note: 'releases' in [1] is 'tags' here)

Why do you think that this structure should work better? I would think that it 
is much easier to use standard ttb layout and let m2 handle each block as 
separate project, rather than building non standard layout.

If I am not mistaken, following should work with m2 right away:

   /cocoon-core
     /trunk
       pom.xml
   /cocoon-blocks-axis
     /trunk
       pom.xml
   /cocoon-blocks-forms
     /trunk
       pom.xml
   /cocoon-standard
     /trunk
       pom.xml (references cocoon-core, cocoon-forms, cocoon-template)
   /cocoon
     /trunk
       pom.xml (references all blocks)

So, what do I miss?


>> Why do you want to reverse this and combine blocks with cocoon core?
> 
> It doesn't reverese anything, all blocks under /trunk will be 
> independent projects, their interdependencies are completely described 
> in the respective POMs.

Where tags and brnaches will live?

Vadim

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112772867005578
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic