You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Moritz Rebbert (JIRA)" <ji...@codehaus.org> on 2008/12/23 02:36:20 UTC

[jira] Issue Comment Edited: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects

    [ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159020#action_159020 ] 

Moritz Rebbert edited comment on MRELEASE-261 at 12/22/08 7:35 PM:
-------------------------------------------------------------------

We also using a "flat" hierarchy for some of our projects.

Based on the assumption of a common ancestor directory that has to be tagged, we started to make a patch.
It workes for us in a simple setup with a parent project in the same folder with some direct modules. Also it should not destroy the behavior in hierarchical layouts.

We do not set or change the workingDirectory variable but compute the common ancestor of all projects where we need it. So we technically devided the location where the pom of the root project resides from the directory which will be tagged(or my be branched).

All projects are tagged under a common directory and "release:perform" also do the job for us.

I've you are brave, you could give "flatProject.main.patch" a try.
We also tried to fix the tests in a reasonable way(flatProject.test.patch).

(We also assume that the layout of the working copy matches the layout in a single repository.)  

Edit: its based on 2.0-beta-9-SNAPSHOT (Last Changed Rev: 726974)

      was (Author: ztiromoritz):
    We also using a "flat" hierarchy for some of our projects.

Based on the assumption of a common ancestor directory that has to be tagged, we started to make a patch.
It workes for us in a simple setup with a parent project in the same folder with some direct modules. Also it should not destroy the behavior in hierarchical layouts.

We do not set or change the workingDirectory variable but compute the common ancestor of all projects where we need it. So we technically devided the location where the pom of the root project resides from the directory which will be tagged(or my be branched).

All projects are tagged under a common directory and "release:perform" also do the job for us.

I've you are brave, you could give "flatProject.main.patch" a try.
We also tried to fix the tests in a reasonable way(flatProject.test.patch).

(We also assume that the layout of the working copy matches the layout in a single repository.)  
  
> release:prepare shouls support flat directory multimodule projects
> ------------------------------------------------------------------
>
>                 Key: MRELEASE-261
>                 URL: http://jira.codehaus.org/browse/MRELEASE-261
>             Project: Maven 2.x Release Plugin
>          Issue Type: Improvement
>          Components: prepare
>         Environment: linux / maven2 / svn
>            Reporter: paul.whelan@gmail.com
>         Attachments: flatProject.main.patch, flatProject.test.patch, PrepareReleaseMojo.patch
>
>
> What I mean by flat file structure firstly.
> parent/pom.xml
> module1/pom.xml
> module2/pom.xml
> .
> .
> .
> module15/pom.xml
> the parent references the modules like so
> <modules>
> 		<module>../module1</module>
> 		<module>../module2</module>
> .
> .
> .
> 		<module>../module15</module>
> </modules>
> When i  release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn.
> I use this structure as i use eclipse as my IDE.
> I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me.
> forgive my english.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira