当我使用maven-release-plugin释放分支时，为什么它尝试从修订版0创建分支？

Question

I'm using the maven-release-plugin. I'm trying to release a branch and it's failing when it tries to execute this command:

cmd.exe /X /C "svn --non-interactive copy --file C:\Users\USER~1\AppData\Local\Temp\maven-scm-711744598.commit --parents --revision 0 https://domain/svn/app/branches/2.4.8.x https://domain/svn/app/tags/App-2.4.8.1"

It gives this error:

svn: E195012: Unable to find repository location for 'https://domain/svn/app/branches/2.4.8.x' in revision 0

I think this is happening in the prepare goal because when it fails it says:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare

I asked a svn expert about this, and he said:

wait, why is it trying to copy something from r0? By definition there is nothing in r0. r0 is always an empty repository, the first objects are added in r1. That's why it fails. the question is why maven tried it. If you supply a revision argument to 'svn copy' then the branch / tag you create is based on the source from the revision you specify so the source has to exist in that revision (if you don't specify, you get HEAD, ie, the newest revision) ...and as for that, I know nothing about maven or its plugins

So why is maven trying to copy from revision 0? This is the maven command I ran:

mvn --batch-mode release:prepare release:perform

And my root pom has the maven-release-plugin defined like this:

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-release-plugin</artifactId>
            <version>2.5</version>
            <configuration>
                <autoVersionSubmodules>true</autoVersionSubmodules>
                <developmentVersion>2.4.8.2-SNAPSHOT</developmentVersion>
                <releaseVersion>2.4.8.1</releaseVersion>
                <branchBase>https://domain/svn/app/branches</branchBase>
                <tagBase>https://domain/svn/app/tags</tagBase>
            </configuration>
        </plugin>

Also, my scm tag looks like this:

<scm>
    <connection>scm:svn:https://domain/svn/app/branches/2.4.8.x</connection>
</scm>

My svn version is 1.8.5 (r1542147)

Answer 1

Just wanted to add this late answer for if anyone has the same problem and the solution in the comment doesn't work.
We had the same problem in a multi module application, only our parent POM had the SCM tag (which worked perfectly in our other applications). We got the same error but could solve it by adding the corresponding SCM tag to each child POM. We never found out why this was...

Answer 2

I also had this problem. In the affected project I had a custom search and replace of some files during the validate phase and I wanted to check in the changes to Svn before tagging so I added a custom check-in action like this:

        <plugin>
            <artifactId>maven-release-plugin</artifactId>
            <configuration>
                <preparationGoals>clean verify scm:checkin -Dmessage="perform release"</preparationGoals>
            </configuration>
        </plugin>

This had the consequences that when the release plugin tried to check in the changes in the pom file, there were no changes since they were already committed by the custom action. Thus causing this error.

I added a "includes" file list to my custom scm:checkin which only included the files that I had been tampering with and this fixed the problem for me.

The resulting configuration looked like this:

        <plugin>
            <artifactId>maven-release-plugin</artifactId>
            <configuration>
                <preparationGoals>clean verify scm:checkin -Dmessage="perform release" -Dincludes="TwogWebUtilsGrailsPlugin.groovy,plugin.xml" -DconnectionType="connection"</preparationGoals>
            </configuration>
        </plugin>

The reason for my custom replace action is because the project is a Grails plugin and I was following the guidelines in this blog post .

LATE EDIT: After upgrading to maven 3.2, this solution seems to break. I am back to where I started.

Answer 3

As I said as a comment above:

I cleaned up EVERYTHING and ran just release:prepare by itself and it succeeded without issue. Perhaps this is a bug where running release:prepare and release:perform together will cause this

I have not run into this issue since running these commands separately.