Maven 2.x Release Plugin

Unable to set the working directory for projects where the master pom isn't at the root of the project

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 2.0-beta-7
  • Fix Version/s: 2.0
  • Component/s: scm
  • Labels:
    None
  • Patch Submitted:
    Yes
  • Number of attachments :
    2

Description

Branches and Tags are created from the current working directory, which isn't always correct and there isn't a way to override the working directory.

For example, we have the following directory structure:

${root}/master/pom.xml - The modules section include relative paths to modules a, b, and c.
${root}/module-a/pom.xml
${root}/module-b/pom.xml
${root}/module-c/pom.xml

All subversion copies (via branch or prepare) originate from ${root}/master. As a result, they are incomplete; we really want to create copies from ${root} not ${root}/master. Here's the subversion command that I think is the problem:

[INFO] Working directory: C:\devsys\repos\trunk\master
[INFO] Branching release with the label release-1.0...
[INFO] Executing: svn --non-interactive copy --file C:\Users\cnelson\AppData\Local\Temp\maven-scm-1179760787.commit . http://hostname/svn/dev/branches/release-1.0

The period after the filename is what's indicating to subversion to create the copy from master instead of ${root}. Note: the working directory is derived from the basedir and I couldn't find a way to override the basedir.

While not having the master pom at the root of the project may be a little uncommon, it doesn't seem unreasonable. Can we add a configuration option to handle these cases?

Issue Links

This issue duplicates:
MRELEASE-261 release:prepare should support flat directory multi-module projects Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Pavel Muller added a comment -

I've got the same problem. Real blocker for our project.

Show
Pavel Muller added a comment - I've got the same problem. Real blocker for our project.
Hide
Permalink
Markus Klink added a comment -

I actually always had the impression that multiprojects encourage that a directory structure like the one outlined above is chosen. I was therefor very surprised to find out that maven release does not support it. How am I supposed to have my directory structure to be able to actually perform a release? For me this is a critical blocker, please fix.

Regards
Markus

Show
Markus Klink added a comment - I actually always had the impression that multiprojects encourage that a directory structure like the one outlined above is chosen. I was therefor very surprised to find out that maven release does not support it. How am I supposed to have my directory structure to be able to actually perform a release? For me this is a critical blocker, please fix. Regards Markus
Hide
Permalink
Torben S. Giesselmann added a comment -

How about using the option -DcommitByProject=true ?
Does that change anything?

Show
Torben S. Giesselmann added a comment - How about using the option -DcommitByProject=true ? Does that change anything?
Hide
Permalink
Paolo Compieta added a comment -

the 'commitByProject' option only affects commit, not tagging.
so we have separate commits for each module but only one tagging - for the parent project.

i designing just now the company-wide maven approach (we'll be using both Idea and Eclipse): this bug is really annoying - fix greatly appreciated.

Regards
Paolo

Show
Paolo Compieta added a comment - the 'commitByProject' option only affects commit, not tagging. so we have separate commits for each module but only one tagging - for the parent project. i designing just now the company-wide maven approach (we'll be using both Idea and Eclipse): this bug is really annoying - fix greatly appreciated. Regards Paolo
Hide
Permalink
Nils Winkler added a comment - - edited

I am facing the same problem. Did some work on this, please have a look at the two attached patches. Here's what they do (in addition to bumping up the version to 1.1-SNAPSHOT, which probably isn't that great - but it works to tell them apart from the official version):

maven-release-plugin-flat.patch

  • Moves the commitByProject attribute up to the AbstractReleaseMojo class. This way this attribute is available for both the prepare and the perform goals.

maven-release-manager-flat.patch

  • If the commitByProject parameter is set, the tagging also goes through the list of projects in the reactor and commits each one of them.
  • During the perform phase, the working directory is set to the directory containing the parent POM, i.e. master/target/checkout/master

You can run this like this:

master> mvn -DcommitByProject=true release:prepare
master> mvn -DcommitByProject=true release:perform

The tag patch currently expects a SCM management layout like this - tested with SVN:

/project
      +trunk
            +master
            +module-a
            +module-b
      +tags
            +foo-1.0
                 +master
                 +module-a
                 +module-b

I have implemented it like this since it reflects our current environment. To use a different layout, I would recommed playing around with the code in ScmTagPhase.java. Maybe another parameter could be added to specify the SCM layout to use.

Hope this helps some of you.

Show
Nils Winkler added a comment - - edited I am facing the same problem. Did some work on this, please have a look at the two attached patches. Here's what they do (in addition to bumping up the version to 1.1-SNAPSHOT, which probably isn't that great - but it works to tell them apart from the official version):

maven-release-plugin-flat.patch

  • Moves the commitByProject attribute up to the AbstractReleaseMojo class. This way this attribute is available for both the prepare and the perform goals.

maven-release-manager-flat.patch

  • If the commitByProject parameter is set, the tagging also goes through the list of projects in the reactor and commits each one of them.
  • During the perform phase, the working directory is set to the directory containing the parent POM, i.e. master/target/checkout/master
You can run this like this: 
master> mvn -DcommitByProject=true release:prepare
master> mvn -DcommitByProject=true release:perform
The tag patch currently expects a SCM management layout like this - tested with SVN: 
/project
      +trunk
            +master
            +module-a
            +module-b
      +tags
            +foo-1.0
                 +master
                 +module-a
                 +module-b
I have implemented it like this since it reflects our current environment. To use a different layout, I would recommed playing around with the code in ScmTagPhase.java. Maybe another parameter could be added to specify the SCM layout to use. Hope this helps some of you.
Hide
Permalink
Maria Odea Ching added a comment -

Fixed in trunk 778088. See MRELEASE-261

Show
Maria Odea Ching added a comment - Fixed in trunk 778088. See MRELEASE-261

People

Vote (10)
Watch (9)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.