release:prepare should support flat directory multi-module projects

Hi John.

Thanks for the update.
In "we have converted", does that mean there is an immediate fix, or rather that we need to wait for a future release?

Also, we have scenarios where you may have:

Parent (under cvs:/group/module1)

• ProjectA (under cvs:/group/module2)
• ProjectB (under cvs:/anotherGroup/module3)

Will that work in this scenario?

Well in that case the common directory is '/' which is probably not what you want as all other folders under '/' would be operated on (checked-in, tagged, etc). Our assumption has been that there is some unifying directory that represented the logical base for the modules underneath it.

We have a similar setup in regards to your master corporate pom project, that can, via a profile, include all our other projects. i.e.

/corporate-pom/pom.xml
/project-a/ - lots of submodules etc
/project-b/ - lots of submodules etc
etc

project-a and project-b, etc all have corporate-pom as their parent and, as i've said, corporate-pom can build all the projects (a,b, etc) (via a profile that include <modules><module>../project-a</module> etc </modules>) but one would not want to release the corporate-pom AND all these other projects at the same time. The 'all projects' setting on the corporate-pom is just for building a master site.

In our setup one releases corporate-pom, project-a , project-b etc separately as they represent completing different projects with their own release cycles etc.

Re when will it be avilable? Well we've done the analysis but I'm off for 2 days now so I expect we won't get patches submitted until next week.

Great Stuff Guys

I am not in the office to create a release till the end of the month. I have to say I am having problems with many plugins as a result of using the flat file structure (site plugin for one). This is great news for me as it will save me a lot of time as you can imagine if a project has lots of modules it can become a real pain to do things by hand.

Thanks for your hard work.

Hi Paul, we have no problems with the site plugin (bar multiple parents being included in the parent menu, see the recently updated MSITE issues) but that is using a site plugin that we've built ourself with a number of patches applied. Specifically though it works for 'flat multimodule' structures.

Hi John,

Any news on the patch? I have browsed the repository, but it doesn't look like any fixes has been applied regarding this issue.

I got an email from John Allen that signified his team did not make significant progress on modifying the plugin, and has since abandoned the research, using, instead, a plugin to modify eclipse imports.

I'm looking at the solution he found – http://eclipse-tools.sourceforge.net/projecttransfer/usage.html –
but I don't think it will work for us.

Paul, have you been able to make any progress?

Nope Sorry I got no where I just put up with the pain.

Paul

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)

Hi all,

making assumption about directory structure and the fact there is a common ancestor is wrong too!

I have this svn structure

• http://server/project/topModule/trunk/pom.xml
• http://server/project/Module1/trunk/pom.xml
• http://server/project/Module2/trunk/pom.xml

and the developper desktop structure based on that svn:

/home/user/dev/project/topModule (=http://server/project/topModule/trunk/)
+ pom.xml
+ Module1 (=http://server/project/Module1/trunk/)
+ pom.xml
+ Module2 (=http://server/project/Module2/trunk/)
+ pom.xml

I expect release plugin to read the submodules pom files, and especially the <scm> entries in that poms, that clearly indicate the svn path of each submodule, which should be tagged as this (using 1.1.1 as release version):

• http://server/project/topModule/tags/1.1.1/pom.xml
• http://server/project/Module1/tags/1.1.1/pom.xml
• http://server/project/Module2/tags/1.1.1/pom.xml

currently, only the first tag is generated, not the submodules tags.

The idea is that, during release, if plugin encounter a submodule which as a <scm> which is different than that of parent, it should also tag it.

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>
             <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-release-plugin</artifactId>
             <version>2.0-beta-7-PATCHED</version>
             <configuration>
                            <tagWorkingDirectory>${basedir}/..</tagWorkingDirectory>
                            <preparationGoals>
                                        clean verify -f ${artifactId}/pom.xml
                             </preparationGoals>
                             <connectionUrl>scm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}</connectionUrl>
                             <goals>clean 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

does the 2.0-beta-8-SNAPSHOT version already includes this fix? If not how can i use the patched version?

I tried apply your workaround to the 2.0-beta-8-SNAPSHOT but got the following error:

[INFO] ----------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO] task-segment: [clean, verify]
[INFO] ----------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Thu May 22 17:04:49 CEST 2008
[INFO] Final Memory: 1M/3M
[INFO] ------------------------------------------------------------------------
[INFO] --------------------------------------------------------------------

Tnx

• Robin

Here's what we did for a workaround:

In the example above, I would have created a POM.XML in the D:\TEMP\MYSTUFF directory with one sub module, ROOT\POM.XML. No projects refer to it as a parent. It is only a way to identify which sub-module is the "real" root.

When doing our development in eclipse, we don't have that new POM.XML available. It only shows up when we checkout the whole project. We then run the Manven release:branch and release:prepare mojos from that directory, and everything seems to work fine.

Example:

proj\+pom.xml (sub module: base)
        |
        |--base
        |    |+pom.xml (sub modules: ../client, ../server)
        |
        |--client
        |    |+pom.xml (parent: ../base)
        |
        |--server
             |+pom.xml (parent: ../base)

All maven release stuff is done from the proj directory, but all of the eclipse projects are at their specific project level.

If a fix is done for this, I would love to help out with the testing. We have a relatively complicated configuration (3 levels of hierarchy) that I could test against.
Thanks - Neil

Yes it's work fine,
and it's not a bad concept to have a "build" pom and a "parent" separated.

In our case, the "root" pom is a child of the "parent" in order to benefit the release change version system and retrieving SCM information.

The only bad news is that the generated site mention the "root" module as a real separated module.
But it could be used as a kind of information build summary page.

Any news on this. Not being able to release a flat structure is a real PITA - and having nearly empty pom.xml's around just to satisfy maven is really bad publicity...

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)

I see there are several patches attached to this issue.
What's the current status? Have any of patches been reviewed/tested? Is there something else that non-committers can provide to help in fixing the issue?

I'm currently working on fixing flat multi-module issues with Continuum and I'd probably be touching this issue since Continuum and the maven-release-plugin use the same release manager component. I'll take a look at the attached patches when I get to fixing the releasing part of flat multi-modules.

See comments in CONTINUUM-1569 for details on how we're approaching this in Continuum..

A workaround that I have used successfully in the past has been:

1. Organize the modules and parent in a flat pattern with <module>../module1</module> etc. in the parent.
2. Add an aggregator pom with one module - the parent. - one level up in the file tree.

Eclipse can ignore the aggregator as it is not referenced by any pom.
The release plugin can release from the aggregator.

Attaching MRELEASE-261.patch..

The base working directory and the base scm url is determined based on the root project's working dir and scm url, and the relative path of it's modules. Tested the fix with Continuum and the maven-release-plugin.

I'm not very familiar with the source code of the Maven Release component so I would really appreciate it if someone could review the fix before I commit it to trunk. Thanks in advance..

Any chance you create an it test for that ?

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.

Attaching revised patch with integration tests for a flat multi-module project and a regular multi-module project.

I can't find particular issue (only tested with svn) .
So +1 to commit this.

Attached patch with a couple of fixes for the tag url written in the pom and additional tests.

If no one objects to the fix I did, I'll commit it to trunk already..

Fixed in trunk 778088 (applied MRELEASE-261-with-its-v3.patch).

Additional fix for determining the common path which was failing in windows was committed to trunk -r778269.

Sample project that still has release issues in a flat structure

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:

[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

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

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

Here's a cat of svn-msg:

emiles-macbook:~ emiles$ cat /tmp/svn-msg 
[maven-release-plugin] prepare release release-parent-0.0.1emiles-macbook:~ emiles$ 

And a cat of targets:

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

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?

Re-opened issue due to last comment.

Eric,

I tried to have a look at the sample project you supplied, but all I find in the archive is something that looks like a file for Eclipse.
Do you have a Maven project that can be used to reproduce your problems?

The file I've attached has 3 subdirectories, each with a pom in it. I have re-downloaded the archive attached to this JIRA and it works fine. It is in tar.gz format, make sure you are downloading the maven-release-issue.tar.gz file.

Re-uploading Eric's sample project, this time in regular zip-format without any Eclipse files. The .tar.gz file has a strange format that can't be extracted using 7-zip on Windows. Even the Archive Manager on Ubuntu didn't like it.

Eric, are you sure that the contents of '/Users/emiles/Projects/release-workspace' really is a Subversion working copy?

What does this command tell you?

ls -la /Users/emiles/Projects/release-workspace

Dennis,

I know this isn't a working directory. This is the eclipse workspace folder that contains the three projects and is the parent directory to the parent pom project. Here is my directory structure:

release-workspace\
        |
        |--release-parent
        |    |+pom.xml (modules: ../release-module1, ../release-module2)
        |
        |--release-module1
        |    |+pom.xml (parent: ../release-parent)
        |
        |--release-module2
             |+pom.xml (parent: ../release-parent)

I am issuing the release:prepare from the release-parent directory, so there should be no reason I receive this error.

I have asked a coworker on a Windows box to pull down the sample project attachment, he had no problems opening it with 7zip. In any case, I'm attaching another sample project archived in a zip format. Please see http://jira.codehaus.org/secure/attachment/46726/maven-release-issue.zip
.

A zip archive of the sample project I have provided

Eric,

Are you saying that Subversion is complaining about the status of '/Users/emiles/Projects/release-workspace' which is a folder that is not under svn control, that only contains three folders that are themselves checked out from Subversion?

Dennis,

That is correct. The only operation performed is the release:prepare from within an SVN managed folder (the parent POM project folder), which happens to be a sub-folder of the folder SVN is complaining about..

OK then, I've looked through the code where things are breaking down.

Could you please try this at your end:

mvn release:prepare -DcommitByProject=true

Screen shot of the odd tagging performed with the flat project structure

Dennis,

The good news is that the prepare goal SOMEWHAT worked. While it was able to change the POMs and check those in appropriately, however it failed on tagging the release. Instead of having tag for each one of the modules (which is what I would expect), only the parent pom project was tagged and was tagged in an odd way. I'm attaching a screenshot, but the tag contains a branches, tags, and trunk folder underneath the tag. Take a look at the odd-tags.png file I have attached.

Ignoring the tagging issue, I attempted to perform the release itself. This is the error I received:

emiles-macbook:release-parent emiles$ mvn release:perform -DcommitByProject=true
[INFO] Scanning for projects...
[INFO] Reactor build order: 
[INFO]   Unnamed - com.captechventures:release-parent:pom:0.0.3-SNAPSHOT
[INFO]   Unnamed - com.captechventures:release-module1:jar:0.0.3-SNAPSHOT
[INFO]   Unnamed - com.captechventures:release-module2:jar:0.0.3-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - com.captechventures:release-parent:pom:0.0.3-SNAPSHOT
[INFO]    task-segment: [release:perform] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [release:perform {execution: default-cli}]
[INFO] Checking out the project to perform the release ...
[INFO] Executing: /bin/sh -c cd /Users/emiles/Projects/release-workspace/release-parent/target && svn --non-interactive checkout http://localhost/dev/release-parent/tags/release-parent-0.0.2 /Users/emiles/Projects/release-workspace/release-parent/target/checkout
[INFO] Working directory: /Users/emiles/Projects/release-workspace/release-parent/target
[INFO] Executing goals 'deploy'...
[WARNING] Base directory is a file. Using base directory as POM location.
[WARNING] Maven will be executed in interactive mode, but no input stream has been configured for this MavenInvoker instance.
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error executing Maven.

Working directory "/Users/emiles/Projects/release-workspace/release-parent/target/checkout/Users/emiles/Projects/release-workspace/release-parent" does not exist!
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5 seconds
[INFO] Finished at: Mon Jan 04 12:22:31 EST 2010
[INFO] Final Memory: 11M/20M
[INFO] ------------------------------------------------------------------------

I had a configuration that I followed from one of the test cases checked in, where the workingDirectory was specified in the configuration of the plugin. seen as follows:

			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-release-plugin</artifactId>
				<version>2.0-beta-10-20091102.165928-8</version>
				<configuration>
					<workingDirectory>${basedir}/target/checkout</workingDirectory>
					<useReleaseProfile>true</useReleaseProfile>
					<allowTimestampedSnapshots>true</allowTimestampedSnapshots>
				</configuration>
			</plugin>

I thought maybe this was the reason for the error, so I removed the workingDirectory configuration, performed all my checkins, did a prepare and attempted to release again and I received the same error as what is identified as above (I'm assuming this directory is the default config).

Eric,

I've been playing around with your example on my virtual Ubuntu to try to reproduce your problems.

I'm having problems understanding what the directory structure in SVN looks like for your example.
Can you please describe it for us?

Here's what I think, based on the POMs.

+--release-parent/trunk/pom.xml
|
+--release-module1/trunk/pom.xml
|
+--release-module1/trunk/pom.xml

Is that correct?

Is that how multi module projects with a flat structure are usually stored in SVN?

Dennis,

Yes, you are correct in that's the structure. I'm not sure how "flat" multi-module projects are usually stored in SVN, however, I'm a consultant and have been on 3 different clients/projects i the last 2 years and all 3 of these clients had their subversion repo setup this way (were setup LONG before I got there).

Regardless, I would think the release plugin would work appropriately no matter what my SVN structure is considering that metadata is provided in the POM. I would think it shouldn't care how it's stored in SVN (or any SCM for that matter) nor should it care what structure it is in as long as the parent pom is available (in the reactor or available via relativePath).

I'm guessing that's a false assumption at this point

Eric,

After more digging in the source code I found an Integration Test for a flat multi module project.
http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-plugin/src/it/flat-multi-module/

This project only has an SCM element in the parent project. This is what I was expecting to find. Have a look at it and see if it can help you in any way.

If you have a multi module project that you want to release all in one go, then that should also be reflected in the SCM, by having a single trunk for the entire multi module project.

Dennis,

So I guess you're saying that it's impossible for the release plugin to support the following SVN structure (or there are no future plans to support it)?

svnroot
|
+--release-parent/trunk/pom.xml
|
+--release-module1/trunk/pom.xml
|
+--release-module1/trunk/pom.xml

The reason I ask is I am often brought on client/projects LONG after their SVN repos are setup and whether or not they can use the release plugin (especially for large projects) would be a big determinator for me in a Maven recommendation. Trust me, I'd prefer if clients could/would reposition their SVN repo and existing projects so multi-module builds "just worked".

It sounds like the definition of a flat structure in this particular test case is all projects "flattened" behind a single trunk/branch/tag. My use case are the projects are flattened at the SVN root level, but each have their own trunk/branches/tags. It seems as though my use case is a hybrid of the typical maven setup and the flattened use case you have provided.

Thanks for explaining Eric,

It does seem that the problem you have is slightly different than the one covered by his issue.

The reason why I'm asking all these questions is that I haven't worked with flat projects before. Because of that I'm not in a position to say if there are any future plans for such a feature.

Would you mind opening up a new JIRA issue for your problem, so that we don't loose it. I'll link the two issues together.

One final question, to give me a better understanding of your use case.
Why do you (or your clients) have branches/tags/trunk for each module, when you (or they) release them all together?

Dennis,

No problem with the questions. When I get enough time, I'll create a new JIRA and reference here in the comments.

I wish I could answer why they have setup their repositories this way, I certainly would have steered them otherwise if I had been there during initial infrastructure setup. My current client I'm pushing to move to the more traditional nested model for Maven multi-module projects, but it's not a quick process. One multi-module build of theirs contains over 36 modules (and an obvious candidate for breaking into smaller project)!

Thanks again for your help.

The reason this was reopened turned out to be a variation on this issue. A new issue will be created for that variation. Closing this one as fixed now.

New issue created, and mentioned in the description.

MRELEASE-516

this has caused a small issue on tagging with projects that have modules like so:
<module>sub/module</module>

I have a test case to reproduce it and will rework the path manipulations to pass that and the additional tests for flat projects.

additional issue fixed and tests added

I still have trouble with multi module builds and cvs, i did create a test-project with one parent and 2 modules and set the maven-release-plugin to 2.0. When i run release:prepare i'm getting the following:

 
C:\work\workspaces\maven\test-main>mvn release:prepare -Dusername=rt55 -Dresume=false -DcommitByProject=true
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Unnamed - test:test-main:pom:0.0.1
[INFO]   Unnamed - test:modul2:jar:0.0.1-SNAPSHOT
[INFO]   Unnamed - test:modul1:jar:0.0.1-SNAPSHOT
[INFO] Searching repository for plugin with prefix: 'release'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - test:test-main:pom:0.0.1
[INFO]    task-segment: [release:prepare] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C "cvs -z3 -d :pserver:rt55@cvsserver:/home/cvs/repository/test -n -q update -d"
[INFO] Working directory: C:\work\workspaces\maven\test-main
[INFO] Checking dependencies and plugins for snapshots ...
...
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Reactor Summary:
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Unnamed - test:test-main:pom:0.0.1 ...... SUCCESS [3.609s]
[INFO] [INFO] Unnamed - test:modul2:jar:0.0.1 ......... SUCCESS [1.157s]
[INFO] [INFO] Unnamed - test:modul1:jar:0.0.1 ......... SUCCESS [0.531s]
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD SUCCESSFUL
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 5 seconds
[INFO] [INFO] Finished at: Tue Aug 24 14:25:39 CEST 2010
[INFO] [INFO] Final Memory: 21M/254M
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "cvs -z3 -q commit -R -F C:\DOCUME~1\rt55\LOCALS~1\Temp\scm-commit-message5089.txt pom.xml"
[INFO] Working directory: C:\work\workspaces\maven\test-main
[INFO] Executing: cmd.exe /X /C "cvs -z3 -q commit -R -F C:\DOCUME~1\rt55\LOCALS~1\Temp\scm-commit-message5091.txt pom.xml"
[INFO] Working directory: C:\work\workspaces\maven\test-module2
[INFO] Executing: cmd.exe /X /C "cvs -z3 -q commit -R -F C:\DOCUME~1\rt55\LOCALS~1\Temp\scm-commit-message5093.txt pom.xml"
[INFO] Working directory: C:\work\workspaces\maven\test-module1
[INFO] Tagging release with the label test-main-0_0_1...
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] The scm url is invalid.
  - The connection string contains too few tokens.

Now, the changes are correctly checked, so i assume the scm url is correct, or ?

  <scm>
     <connection>scm:cvs|pserver|${maven.scm.username}@cvsserver|/home/cvs/repository/test|maventest_main</connection>
  </scm>

Am I doing something wrong ?

Michael,

While the flat structure is supported, it's very particular about how it's structured. I wrote a series of blog posts on this. The third in the series can be found at the following link, and that post has pointers to the first 2 (I recommend reading them in order).

http://ericmiles.wordpress.com/2010/02/08/maven-release-non-supported-scm-structures/

After some digging i think the patch for flat modules is broken for cvs. It seems the recent patch to tag SVN correctly did stop CVS from tagging it. If i look into ScmTagPhase the ScmRepository gets initialized with:

repository =
      scmRepositoryConfigurator.getConfiguredRepository( basedirAlignedReleaseDescriptor.getScmSourceUrl(),
                                                                   releaseDescriptor,
                                                                   releaseEnvironment.getSettings() );

But basedirAlignedReleaseDescriptor.getScmSourceUrl() yields "...cvsserver|/home/cvs/repository", note the missing project AND the missing module ...

If i change it to the same code the SvnCommitPhase is using things are starting to look better, when i change the ScmFileSetConstructor back to releaseDescriptor.getWorkingDirectory() the tags are written to the main project at least. (But this of course breaks the SVN tagging ...)

@Eric,
thanks for the links, nice explanation of the problem, but i'm stuck with cvs, you only present some solution for svn, or did i miss something ?

I'd like to share my use case with you to understand why people may have 'unusual' project structures.
I think that my problem is the same as the one in this issue, but not sure.
So, my apologizes if this does not fit 100% and should be posted to MRELEASE-516

We started with the following set up:

ModuleA/trunk/pom.xml
ModuleB/trunk/pom.xml
ModuleC/trunk/pom.xml

These were more or less independent artifacts and the release process was just releasing those three artifacts individually.
Every module's pom.xml has its own <scm> element.
After a while, additional modules were implemented and a common parent pom was introduced, hence the structure became:

Parent/trunk/pom.xml
ModuleA/trunk/pom.xml
ModuleB/trunk/pom.xml
...
ModuleY/trunk/pom.xml
ModuleZ/trunk/pom.xml

Now, the release process for many modules takes up a lot of time and the idea is to aggregate all the releases into
a single release step from a release manager point of view. So, a reactor build is put on top of the whole thing:

Everything/trunk/pom.xml (Modules: ModuleA, ModuleB ... ModuleZ)
ModuleA/trunk/pom.xml
ModuleB/trunk/pom.xml
...
ModuleY/trunk/pom.xml
ModuleZ/trunk/pom.xml

The Everything-pom.xml contains the modules:

<modules>
	<module>ModuleA</module>
	<module>ModuleB</module>
	<module>...</module>
	<module>ModuleY</module>
	<module>ModuleZ</module>
</modules>

Then, all the trunks are checked out from SCM (SVN, using the svn:externals property) into the local working copy, so they reflect the correct
structure without any 'trunk' folders or relative paths like "../ModuleA".

pom.xml (from Everything/trunk/pom.xml)
+ ModuleA/pom.xml
+ ModuleB/pom.xml
...
+ ModuleY/pom.xml
+ ModuleZ/pom.xml

Now, i'm trying to perform a release in the root of this folder, e.g. the "Everything" project.
The reactor will prepare all modules, but unfortunately, the SVN tag of each module is overwritten and becomes incorrect.
Each module should be committed to its own 'tags/' folder with name and version of the module.
However, what actually happens is, the release plugin replaces all SCM URLS of each module with the name of the Everything-pom.xml:

Actually in pom.xml.tag: <url>scm:svn:.../ModuleA/tags/Everything-1.0/ModuleA/trunk</url>
Expected in pom.xml.tag: <url>scm:svn:.../ModuleA/tags/ModuleA-1.0</url>

@Mike R. Haller
I'm using CVS so I have the problem that the release plugin doesn't work for flat project structures correctly.
But the other problem you describe about the entry of the reactor/Everything project to the poms of the child projects I also can reconstruct with the <tag> element in the <scm> section..

this is NOT FIXED at all!

please take a look at MRELEASE-138 too