[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-tabpanelfocusedCommentId=203270#action_203270
]
Eric Miles edited comment on MRELEASE-261 at 12/21/09 2:04 PM:
---
I'm not 100% sure this is fixed. I setup a project to use the beta-10-SNAPSHOT
plugin and it is still not working, I'm getting the following error while
trying to prepare the release:
{code}
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd
/Users/emiles/Projects/release-workspace/release-parent svn
--non-interactive commit --file
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-1253932520.commit
--targets
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-4376558781490229966-targets
[INFO] Working directory:
/Users/emiles/Projects/release-workspace/release-parent
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: '/Users/emiles/Projects/release-workspace' is not a working copy
{code}
I have confirmed that I am using the beta 10 release as well as I have
confirmed the beta 10 release in Apache snapshots contained the v3.patch
identified in one of the previous comments. I'm attaching my sample project,
maven-release-issue.tar.gz. I'm hoping this can be used as a test case and/or
someone can tell me if I've set the project up incorrectly.
This work is being performed in a Mac OS X environment with JDK 1.5 and SVN
1.6.6.
An update...I have completely removed the release plugin and am only using the
svn binary on my box. I still get the same issue, issuing a similar command
{code}
emiles-macbook:~ emiles$ svn --non-interactive commit --file /tmp/svn-msg
--targets /tmp/targets
svn: '/Users/emiles/Projects/release-workspace' is not a working copy
{code}
Here's a cat of svn-msg:
{code}
emiles-macbook:~ emiles$ cat /tmp/svn-msg
[maven-release-plugin] prepare release release-parent-0.0.1emiles-macbook:~
emiles$
{code}
And a cat of targets:
{code}
emiles$ cat /tmp/targets
/Users/emiles/Projects/release-workspace/release-parent/pom.xml
/Users/emiles/Projects/release-workspace/release-module1/pom.xml
/Users/emiles/Projects/release-workspace/release-module2/pom.xml
{code}
So that this point, I'm beginning to wonder if it's the svn binary causing an
issue, at this point we have completely circumvented the release plugin. Or
maybe it's the way the release plugin is attempting to use SVN?
was (Author: bigehokie):
I'm not 100% sure this is fixed. I setup a project to use the
beta-10-SNAPSHOT plugin and it is still not working, I'm getting the following
error while trying to prepare the release:
{code}
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd
/Users/emiles/Projects/release-workspace/release-parent svn
--non-interactive commit --file
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-1253932520.commit
--targets
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-4376558781490229966-targets
[INFO] Working directory:
/Users/emiles/Projects/release-workspace/release-parent
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: '/Users/emiles/Projects/release-workspace' is not a working copy
{code}
I have confirmed that I am using the beta 10 release as well as I have
confirmed the beta 10 release in Apache snapshots contained the v3.patch
identified in one of the previous comments. I'm attaching my sample project,
maven-release-issue.tar.gz. I'm hoping this can be used as a test case and/or
someone can tell me if I've set the project up incorrectly.
This work is being performed in a Mac OS X environment with JDK 1.5 and SVN
1.6.6.
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.whe...@gmail.com
Assignee: Maria Odea Ching
Fix For: 2.0-beta-10
Attachments: flatProject.main.patch, flatProject.test.patch,
maven-release-issue.tar.gz, MRELEASE-261-with-its-v3.patch,
[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-tabpanelfocusedCommentId=176245#action_176245 ] Maria Odea Ching edited comment on MRELEASE-261 at 5/13/09 6:01 AM: I only have unit tests for getting the base working dir and base scm url. I just saw the it tests in maven-release-plugin now, I'll see if I can write one for a flat multi-module. was (Author: oching): Just unit tests for getting the base working dir and base scm url. I just saw the it tests in maven-release-plugin now, I'll see if I can write one for a flat multi-module. 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.whe...@gmail.com Attachments: flatProject.main.patch, flatProject.test.patch, MRELEASE-261.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
[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-tabpanelfocusedCommentId=159020#action_159020 ] Moritz Rebbert edited comment on MRELEASE-261 at 12/26/08 7:11 AM: --- 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 may 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.) Edit: its based on 2.0-beta-9-SNAPSHOT (Last Changed Rev: 726974) 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.whe...@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
[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-tabpanelfocusedCommentId=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.whe...@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
[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-tabpanelfocusedCommentId=129890#action_129890
]
aleggett edited comment on MRELEASE-261 at 4/5/08 8:36 AM:
---
Attaching a prospective workaround patch for this issue.
Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo.
Then in your relative parent pom you can configure like this:
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0-beta-7-PATCHED/version
configuration
tagWorkingDirectory${basedir}/../tagWorkingDirectory
preparationGoals
clean verify -f ${artifactId}/pom.xml
/preparationGoals
connectionUrlscm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}/connectionUrl
goalsclean deploy/goals
pomFileName${artifactId}/pom.xml/pomFileName
arguments-f ${artifactId}/pom.xml/arguments
/configuration
/plugin
{noformat}
The additional config is to ensure the parent pom gets found for the forked
lifecycles in release:prepare and release:perform. In addition, due to the
release manager now putting the release descriptor (release.properties) in
$[basedir}/.. you need to specify the connectionUrl for release:perform. I
guess you could write some script to move it or, as above, fill in the url
apart from the release version e.g.
{noformat}
#hello-world/hello-world-parent mvn release:prepare release:perform
-Drelease.version=1.7 --batch-mode
{noformat}
Hope this is useful.
Adam
was (Author: aleggett):
Attaching a prospective workaround patch for this issue.
Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo.
Then in your relative parent pom you can configure like this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0-beta-7-PATCHED/version
configuration
tagWorkingDirectory${basedir}/../tagWorkingDirectory
preparationGoals
clean verify -f ${artifactId}/pom.xml
/preparationGoals
connectionUrlscm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}/connectionUrl
goalsclean deploy/goals
pomFileName${artifactId}/pom.xml/pomFileName
arguments-f ${artifactId}/pom.xml/arguments
/configuration
/plugin
The additional config is to ensure the parent pom gets found for the forked
lifecycles in release:prepare and release:perform. In addition, due to the
release manager now putting the release descriptor (release.properties) in
$[basedir}/.. you need to specify the connectionUrl for release:perform. I
guess you could write some script to move it or, as above, fill in the url
apart from the release version e.g.
#hello-world/hello-world-parent mvn release:prepare release:perform
-Drelease.version=1.7 --batch-mode
Hope this is useful.
Adam
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
Environment: linux / maven2 / svn
Reporter: [EMAIL PROTECTED]
Attachments: 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
[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-tabpanelfocusedCommentId=129890#action_129890
]
aleggett edited comment on MRELEASE-261 at 4/5/08 8:39 AM:
---
Attaching a prospective workaround patch for this issue.
Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo.
Then in your relative parent pom you can configure like this:
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0-beta-7-PATCHED/version
configuration
tagWorkingDirectory${basedir}/../tagWorkingDirectory
preparationGoals
clean verify -f ${artifactId}/pom.xml
/preparationGoals
connectionUrlscm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}/connectionUrl
goalsclean deploy/goals
pomFileName${artifactId}/pom.xml/pomFileName
arguments-f ${artifactId}/pom.xml/arguments
/configuration
/plugin
{noformat}
The additional config is to ensure the parent pom gets found for the forked
lifecycles in release:prepare and release:perform. In addition, due to the
release manager now putting the release descriptor (release.properties) in
$[basedir}/.. you need to specify the connectionUrl for release:perform. I
guess you could write some script to move it or, as above, fill in the url
apart from the release version e.g.
{noformat}
#hello-world/hello-world-parent mvn release:prepare release:perform
-Drelease.version=1.7 --batch-mode
{noformat}
Hope this is useful.
Adam
was (Author: aleggett):
Attaching a prospective workaround patch for this issue.
Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo.
Then in your relative parent pom you can configure like this:
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0-beta-7-PATCHED/version
configuration
tagWorkingDirectory${basedir}/../tagWorkingDirectory
preparationGoals
clean verify -f ${artifactId}/pom.xml
/preparationGoals
connectionUrlscm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}/connectionUrl
goalsclean deploy/goals
pomFileName${artifactId}/pom.xml/pomFileName
arguments-f ${artifactId}/pom.xml/arguments
/configuration
/plugin
{noformat}
The additional config is to ensure the parent pom gets found for the forked
lifecycles in release:prepare and release:perform. In addition, due to the
release manager now putting the release descriptor (release.properties) in
$[basedir}/.. you need to specify the connectionUrl for release:perform. I
guess you could write some script to move it or, as above, fill in the url
apart from the release version e.g.
{noformat}
#hello-world/hello-world-parent mvn release:prepare release:perform
-Drelease.version=1.7 --batch-mode
{noformat}
Hope this is useful.
Adam
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
Environment: linux / maven2 / svn
Reporter: [EMAIL PROTECTED]
Attachments: 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
[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#action_121577 ] skaze edited comment on MRELEASE-261 at 1/28/08 5:35 PM: -- Subclipse plugin for Eclipse can not handle nested projects in Eclipse at all, and from the dialogue on their list, do not intend to. As Subversive provides much better support for nested Subversion structures in Eclipse, and has since become the 'official' (or so I'm informed) Eclipse foundation Subversion plugin, we have moved to using Subversive and find that the Eclipse multi-project import-export plugin works pretty well. Note the impact analysis for the work of changing the release plugin to be more 'directory aware' was pretty good, 3 days would have it cracked I would expect (inc. ITs etc) was (Author: skaze): Subclipse plugin for Eclipse can not handle nested projects in Eclipse at all, and from that dialogue on their list, do not intend to. As Subversive provides much better support for nested Subversion structures in Eclipse, and has since become the 'official' (or so I'm informed) Eclipse foundation Subversion plugin, we have moved to using Subversive and find that the Eclipse multi-project import-export plugin works pretty well. Note the impact analysis for the work of changing the release plugin to be more 'directory aware' was pretty good, 3 days would have it cracked I would expect (inc. ITs etc) 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 Environment: linux / maven2 / svn Reporter: [EMAIL PROTECTED] 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
[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#action_102611
]
John Allen edited comment on MRELEASE-261 at 7/18/07 12:12 PM:
---
Dear all, we have converted release 3 plugin to work just fine with flat based
multi-modules. The fix works for all maven project structures as it simply
changes an invalid assumption made in the existing code base:-
Currently the 'working directory' of the 'execution project' is assumed to be
the top 'ancestor' directory for which all projects contained within the
reactor will live under. This is obviously incorrect for flat based projects.
The fix is simply a case of determining what the directory in the maven module
hierarchy is the common owning directory for all the projects with the
hierarchy (which for nested projects happens to be of course the same as the
execution project's home, or in other words the working directory').
For instance (please excuse ASCII art)
{code}
A typical nested project hierarchy:
D:\TEMP\MYSTUFF -- HTTP://SVN.ORG/REPOS/MYSTUFF/TRUNK
|+POM.XML
|
|--B
| |+POM.XML
| |
| |--C
| |+POM.XML
|
|--D
| |+POM.XML
|
|--E
|+POM.XML
The same logical hierarchy but expressed as a flat maven structure:
D:\TEMP\MYSTUFF -- HTTP://SVN.ORG/REPOS/MYSTUFF/TRUNK
|--ROOT
| |+POM.XML
|
|--B
| |
| |--B.ROOT
| | |+POM.XML
| |
| |--C
| |+POM.XML
|
|--D
| |+POM.XML
|
|--E
|+POM.XML
{code}
These two are logically equivalent.
The observation is that tagging, branching, checkout, checkin etc are version
controlled based operations and the majority of VCS systems provide a file
system based model (not bothering with object based VC systems here).
So when we want to tag the stuff in MYSTUFF/TRUNK what we really want to do is
create something under the TAGS in SVN (say) that has the trunk contents, thus:
{code}
A typical nested project hierarchy:
HTTP://SVN.ORG/REPOS/MYSTUFF/TAGS/MYTAG-1.0/
|+POM.XML
|
|--B
| |+POM.XML
| |
| |--C
| |+POM.XML
|
|--D
| |+POM.XML
|
|--E
|+POM.XML
And for the flat structure we want:
HTTP://SVN.ORG/REPOS/MYSTUFF/TAGS/MYTAG-1.0/
|--ROOT
| |+POM.XML
|
|--B
| |
| |--B.ROOT
| | |+POM.XML
| |
| |--C
| |+POM.XML
|
|--D
| |+POM.XML
|
|--E
|+POM.XML
{code}
By going through the module hierarchy and finding the common directory ancestor
we are able to perform all the correct SVN operations (CO, CI, TAG, ETC).
i.e. For the nested structure the common ancestor directory IS the current
directory:
{code}
D:\TEMP\MYSTUFF
|+POM.XML
|
|--B
| |+POM.XML
...
{code}
Top common ancestor directory is equal to 'D:\TEMP\MYSTUFF' which happens to be
the same as the working directory of the execution project (the top POM.XML).
The same approach (of working out the common ancestor) works the on a flat
structure but identifies that D:\TEMP\MYSTUFF is the common directory and NOT
the execution projects' working directory which is in fact D:\TEMP\MYSTUFF\ROOT\
{code}
D:\TEMP\MYSTUFF
|--ROOT
| |+POM.XML
|
|--B
| |
| |--B.ROOT
| | |+POM.XML
...
{code}
Cool. So now the only problem is in handling the perform operations where the
plugin needs no project, simply checks out everything from the tag URL.
Checkout works just fine but there is one critical piece of information
missing, namely the path into the 'ROOT' project so that the build can start.
This extra bit of information is simply added to the ReleaseConfiguration (that
is persisted as release.properties). The perform reads this is an makes that
the 'working directory' before it calls maven executor and then kicks off the
build.
Note: Maven is full of assumptions regarding the location of modules being
'beneath' the parent project, for instance the default scheme for constructing
URLs and SCM URLS has the derived projects taking the parent's URL and tacking
its artifactId on the end. For all us flat-project guys you can usually work
around these issues through explicit definition of the elements in the
child/derived projects.
was:
Dear all, we have converted release 3 plugin to work just fine with flat based
multi-modules. The fix works for all maven project structures as it simply
changes an invalid assumption made in the existing code base:-
Currently the 'working directory' of the 'execution project' is assumed to be
the top 'ancestor' directory for which all projects contained within the
reactor will live under. This is obviously incorrect for flat based projects.
The fix is simply a case of determining what the directory in the maven module
hierarchy is the common owning directory for all the projects with the
hierarchy (which for nested projects happens to be of course the same as the
execution project's home, or in other words the working directory').
For instance (please excuse ASCII art)
{code}
A typical nested project
