[
http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102611
]
John Allen commented on MRELEASE-261:
-------------------------------------
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.
> 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
