Apparently my ISP is no longer spam listed so I can risk posting to the list without sending 15 duplicates :)

Emmanuel Venisse wrote:

If you want to use "trunk" in directory structure, I think that is necessary
to add a note on the site for define the directory structure for the
checkout :


The SCM info is correct, but the bootstrap document will have to be updated, yes.

- maven-1
   - core
       - trunk
   - jelly-tags
       - trunk
   - plugins
       - trunk
   - plugins-sandbox
       - trunk

Is it a good idea to use "trunk" in directory structure?
I don't think.


This is the recommended structure given by the SVN developers, being used on other projects, and what was voted into the original proposal.

When we'll branch a module, we'll have maven-1/core/branch/... and it will
be difficult to obtain a good project properties for all users checkout.
Generally, I use a structure like this :


The key is that these are separate projects and need to be separated. In fact, even each plugin might have its own t/b/t set underneath as trygvis suggested - however that is more work that can be done later as necessary.

so, yes, maven-1/core/branches/MAVEN-1_0-BRANCH does exist already, and ../../plugins/trunk will not be the correct property anymore because of the change in depth.
However, a user can still check it out however they wish: without the trunk, or just as core/MAVEN-1_0-BRANCH


I will think about it, but I'd say that relying on maven-plugins being in a certain location was always a bad idea, and it is probably better to think of alternatives.

- maven-1
   - core
   - jelly-tags
   - plugins
   - plugins-sandbox
- maven-1_BranchInformation
   - core
   - jelly-tags
   - plugins
   - plugins-sandbox

With this structure, the build will work with all checkout for all branches.


The same discussion was had at jakarta-commons.

The problem with this is that MAVEN_JELLY_TAGS_1_0_1 only exist on one repository, MAVEN_1_0 only exists on one and MAVEN_EJB_PLUGIN_1_4 only exists on one - none of them crossover.

Still, we can move things, so I'm happy to discuss alternatives.

Cheers
Brett


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to