Right, I figured out what causes this, looking at the maven-release-manager source code. When rewriting the developerConnection
value, the RewritePomsForReleasePhase
class calculates the number of subdirectories we need to remove from the developerConnectionUrl to get to the root of our project, based on the local project. Now there are two problems with this approach:
- There is no guarantee the local depth will match the remote one. Although this may be best practice.
- The working dir (from where mvn is called) does not have to be in the root of the project.
Both apply to my situation. I checked out the project two directories less deep than remote. To clarify:
http://localhost/project/3. Implementation/02 Source code
was checked out to
D:\workspace\project
Also, we have a project-parent
dir containing our parent pom.
So now it determines we are 1 deep by looking at the local structure (from work dir, i.e. project-parent, to project dir) and applies this to the developerConnection url. Then it does a substring on the original developerConnection with the result and ends up with 02 Source code
in my case.
So long story less long: maven-release-plugin does not work as expected when the local directory structure does not match the remote one. Now I have to checkout honoring the server path and also create a new pom, or move the parent pom to the project root to get it to work...
EDIT: Moving the pom to the project base dir would probably fix the issue, leaving the developerConnection url unchanged. Will confirm this for the next release.