release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk

there were changes to locate the root in non-standard layouts - do you have a parent in svn://host/path/project/somewhere-else ? Do you have <connection> set anywhere?

The structure is indeed looking like:

/project
  |-- pom.xml
  |      |--> <scm>
  |      |-->    <developerConnection>
  |      |--> </scm>
  |-- moduleA/
  |-- moduleB/

I will test with <connection> being declared as well.

if /project/trunk is the top level (Assuming that's what you meant here), that's the expected layout. If you have something 'above' trunk or in a directory at the same level as it, that might be the problem.

The project layout is fairly standard (I forgot to indicate the full trunk/tags structure in my snippet above):

/project
  /trunk
     |-- pom.xml
     |      |--> <scm>
     |      |-->    <developerConnection>
     |      |--> </scm>
     |-- moduleA/
     |-- moduleB/
  /tags
  /branches

So:

• I added the <connection> URL in the parent POM (same as developer connection actually)
• I switched back to the maven-release-plugin 2.0 version (in the plugin management section)

The tag is created from the project/

When I use the maven-release-plugin 2.0.9 version, the tag is created from the trunk.

Here is an extract of the parent POM about the release plug-in configuration:

	<build>
		<pluginManagement>
			...
			<plugins>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-release-plugin</artifactId>
					<version>2.0</version>
				</plugin>
			</plugins>
			...
		</pluginManagement>
		<plugins>
			...
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-release-plugin</artifactId>
				<configuration>
					<remoteTagging>true</remoteTagging>
				</configuration>
			</plugin>
			...
		</plugins>
	</build>

Thanks - I'll put this in the list for the next version.

Are you able to reproduce this with a small sample project that you can share with us to make it easier to reproduce?

I will prepare a small project and try to reproduce the problem. I will just have to obfuscate the URLs.

I've created a sample project that allowed me reproduce the problem.

The interesting thing is that I cannot reproduce the problem if I run the release:prepare command from my environment, but only when I run this build from Hudson. So maybe it's linked somehow with Hudson.

Here is the actual build step that is called:

Executing Maven:  -B -f /opt/hudson/jobs/MRelease-526/workspace/./pom.xml -B clean install release:clean release:prepare -DautoVersionSubmodules=true -DreleaseVersion=0.7.0 -DdevelopmentVersion=0.8.0-SNAPSHOT -Dtag=0.7.0 -DpreparationGoals=clean install

And here is the output about the tagging part:

[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /opt/hudson/jobs/MRelease-526/workspace/. && svn --non-interactive commit --file /tmp/maven-scm-1832850485.commit --targets /tmp/maven-scm-1057416757279716410-targets
[INFO] Working directory: /opt/hudson/jobs/MRelease-526/workspace/.
[INFO] Tagging release with the label 0.7.0...
[INFO] Executing: /bin/sh -c cd /opt/hudson/jobs/MRelease-526/workspace && svn --non-interactive copy --file /tmp/maven-scm-1386345960.commit --revision 39 svn://192.168.37.24/maven/mrelease526 svn://192.168.37.24/maven/mrelease526/tags/0.7.0
[INFO] Working directory: /opt/hudson/jobs/MRelease-526/workspace
[INFO] Transforming 'Unnamed - org.apache.maven:mrelease526:pom:0.7.0-SNAPSHOT'...
[INFO] Transforming 'Unnamed - org.apache.maven:moduleA:jar:0.7.0-SNAPSHOT'...
[INFO] Transforming 'Unnamed - org.apache.maven:moduleB:jar:0.7.0-SNAPSHOT'...
[INFO] Not removing release POMs
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /opt/hudson/jobs/MRelease-526/workspace/. && svn --non-interactive commit --file /tmp/maven-scm-1044767202.commit --targets /tmp/maven-scm-4622755560941691278-targets
[INFO] Working directory: /opt/hudson/jobs/MRelease-526/workspace/.
[INFO] Release preparation complete.

Same thing here. But even downgrading the plugin version won't do it.

Each time I run mvn release:prepare it copies the trunk folder into the new tag.

I just tried upgrading to 2.0 and found the same thing. Show stopper bug for us and have to revert back to beta-9.

Same issue with mercurial, tagging fails because the working directory is one level too high.

Same for git. It's a blocker since. 2.0 is useless for git users as far as I can see.
Is this related to MRELEASE-546? Is it fixed by change 933531?

There is a bug in the way the release plugin calculates the path to use as the tag base directory. We have also had this problem and have modified the release plugin (locally) to solve the problem. The cause of the problem is a little bit tricky to explain, but I'll try my best:

The trigger for this problem is as follows:

Suppose we have projects A, B, C and D

    A
    |-B
    |-C
    \-D

• Projects B, C and D are all in the <modules> list of project A.
• Projects C and D have A as parent.
• Project B has no parent (or a parent other than A).

Because project B does not depend on A, it may appear before A in the reactor build order. This can easily be tested for by looking at the "Reactor build order" that appears when you do "release:prepare". Usually you would expect project A to be the first entry in this list.

The program fault:

The faulty code is in the "maven-release-manager" (a module used by the "maven-release-helper").
The file org.apache.maven.shared.release.util.ReleaseUtil in method getCommonBasedir is where the error lies.

This method should find the base directory shared by all projects in the reactor. This directory will be used as the base directory from which to perform the tag.

It works by looking at all paths for all projects in the reactor and finding the "prefix" that is common to all path strings.
E.g.
c:/path/to/projectA-1.5
c:/path/to/projectB-2.1
c:/path/to/projectC-1.0

The "common prefix" would be "c:/path/to/project". Because this is not a valid path (there is no "project" directory) it cuts off the string from the last "/" leaving "c:/path/to".

Returning to our example above: we would have the following input for this method:

c:/path/to/projectA
c:/path/to/projectA/projectB
c:/path/to/projectA/projectC
c:/path/to/projectA/projectD

Because the method needs to return "c:/path/to/projectA" (and not "c/path/to") as the base directory, the algorithm adds an additional "/" to the end of paths to ensure that the "common suffix" is a valid path (i.e. doesn't get shortened as in the first example).
This works fine, but as soon as the project order looks like the following it doesn't work correctly:

c:/path/to/projectA/projectB
c:/path/to/projectA
c:/path/to/projectA/projectC
c:/path/to/projectA/projectD

This is exactly the sequence that you get when B doesn't have A for a parent (the trigger condition).
The algorithm fails to append "/" to the second path and the returned path is "c:/path/to" instead of "c:/path/to/projectA" and this is then used as the base directory for the tag. This is why the generated tag is one level too high in the directory tree.

The fix:

This method at the moment is as follows:

 public static String getCommonBasedir( List reactorProjects, char separator )
    {
        String basedir = null;
        for ( Iterator i = reactorProjects.iterator(); i.hasNext(); )
        {
            MavenProject p = (MavenProject) i.next();

            // we can only normalize paths with /
            String dir = FileUtils.normalize( p.getBasedir().getPath().replace( '\\', '/' ) );

            if ( basedir == null )
            {
                basedir = dir;
            }
            else
            {
                // always end in / so that we know what is a path and what is a partial directory name in the next call 
                if ( !basedir.endsWith( "/" ) )
                {
                    basedir = basedir + "/";
                }

                basedir = StringUtils.getCommonPrefix( new String[]{dir, basedir} );

                if ( !basedir.endsWith( "/" ) )
                {
                    basedir = basedir.substring( 0, basedir.lastIndexOf( "/" ) );
                }
            }
        }

        if ( basedir != null )
        {
            if ( basedir.endsWith( "/" ) && basedir.length() > 1 )
            {
                basedir = basedir.substring( 0, basedir.length() - 1 );
            }
            basedir = basedir.replace( '/', separator );
        }

        return basedir;
    }

It can be changed to the following, which correctly appends "/" to the end of both "basedir" AND "dir", which solves the problem.

    public static String getCommonBasedir(List reactorProjects, char separator) {
        String basedir = null;
        for (Iterator i = reactorProjects.iterator(); i.hasNext();) {
            MavenProject p = (MavenProject) i.next();

            // we can only normalize paths with /
            String dir = FileUtils.normalize(p.getBasedir().getPath().replace('\\', '/'));

            // always end in / so that we know what is a path and what is a partial directory name in the next call
            if (!dir.endsWith("/")) {
                dir = dir + "/";
            }

            if (basedir == null) {
                basedir = dir;
            } else {

                basedir = StringUtils.getCommonPrefix(new String[] { dir, basedir });

                if (!basedir.endsWith("/")) {
                    basedir = basedir.substring(0, basedir.lastIndexOf("/"));
                }
            }
        }

        if (basedir != null) {
            if (basedir.endsWith("/") && basedir.length() > 1) {
                basedir = basedir.substring(0, basedir.length() - 1);
            }
            basedir = basedir.replace('/', separator);
        }

        return basedir;
    }

Sorry for the long post!

same problem here; I observe it only on multimodule projects, and not strictly always - which seems to be confirming the explanation above

as far as I can tell this is the same as the already fixed issue MRELEASE-546 as mentioned earlier. Please let us know if the problem still exists on trunk.

I still have this problem and I just tried release plugin 2.1. If in v2.1 of the plugin I have the fix for issue MRELEASE546, then I believe this isn't exactly the same bug, as I'm still seeing the behaviour others have outlined above, and I have a multi-module project with inheritance also.

This originally all worked fine in v2.0-beta-8 of the plugin

I have to agree with James Bowkett. We did not have this problem with Maven 2.2.1, which comes with the v2.0-beta-8 of the release plugin. Switching to Maven 3.0.3 (i.e. to v2.0 of the plugin) leads to this problem. As far as I can tell this is clearly not a duplicate to MRELEASE-546. Can this issue be changed to another status than closed? Or should I create a new issue? And what about the fix proposed by James Blewitt?

Claus,

Please open a new issue.

Where is the new issue? I have the same prolem with Maven 3.0.3 and the plugin versions 2.0 and 2.1.

The new issue is MRELEASE-679.