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

List:       xml-cocoon-dev
Subject:    Re: [M10N] new repo layout
From:       Daniel Fagerstrom <danielf () nada ! kth ! se>
Date:       2005-11-04 12:57:19
Message-ID: 436B5AAF.9000301 () nada ! kth ! se
[Download RAW message or body]

Vadim Gritsenko wrote:

> 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?

A common tags or rather release area. We only use tags for releases, so 
it would be clearer to call it releases.

> > 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...

Needing to check out a script for chrcking out Cocoon doesn't seem to 
increase usability. Not sure that it would work that well with IDEs either.

> > 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?

If you want to work on all of Cocoon you just checkout trunk, no need 
for scripts or externals. If you want to work on a single block or a few 
of them you just check them out.

> 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.

Jorg says that the layout above works well with m2.

> 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?

See above.

> > > 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?

It is explained in one of the links I asked you to read: 
http://mail-archives.apache.org/mod_mbox/incubator-oscar-dev/200508.mbox/%3c430C3677.5070706@nada.kth.se%3e
 I suggest that you read it. Brett Porter of Maven fame says: 
http://mail-archives.apache.org/mod_mbox/incubator-oscar-dev/200508.mbox/%3c9e3862d8050823183447c38b55@mail.gmail.com%3e
 about top level trunk.

I explained about tags above. For branches it depends, quoting Niclas:

> 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.
> 
Substitute laboratory with whiteboard above.

/Daniel


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