Maven 2.x Release Plugin

mvn release:prepare-with-pom not honouring the commitByProject parameter.

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Blocker Blocker
  • Resolution: Unresolved
  • Affects Version/s: 2.2.2
  • Fix Version/s: None
  • Component/s: Git, prepare-with-pom
  • Labels:
    None
  • Environment:
    Linux 64bit (Ubuntu).
  • Number of attachments :
    5

Description

Using this in my pom file:

			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-release-plugin</artifactId>
				<version>2.2.2</version>
				<configuration>
					<goals>deploy</goals>
					<pushChanges>false</pushChanges>
					<localCheckout>true</localCheckout>
					<commitByProject>true</commitByProject>
				</configuration>
			</plugin>

Running this command:

mvn release:prepare

Correctly goes into each directory to make changes, e.g. 

[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git add -- pom.xml
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git status
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git commit --verbose -F /tmp/maven-scm-561169862.commit pom.xml
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git add -- pom.xml
[INFO] Working directory: /usr/local/src/whitelabel/foundation
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git status
[INFO] Working directory: /usr/local/src/whitelabel/foundation
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git commit --verbose -F /tmp/maven-scm-2018482909.commit pom.xml

etc ...

However running this command:

mvn release:prepare-with-pom

So that I can generate a release-pom.xml file errors because it attempts to do all the checkins on one line:

[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git add -- release-pom.xml foundation/release-pom.xml module/release-pom.xml module/advertising/release-pom.xml module/buttonconfig/release-pom.xml module/core/release-pom.xml module/film/release-pom.xml module/profile/release-pom.xml module/proxy/release-pom.xml module/rental/release-pom.xml module/service/release-pom.xml module/smartcard/release-pom.xml module/telephony/release-pom.xml module/terminalui/release-pom.xml module/tv/release-pom.xml module/upsell/release-pom.xml module/urlconfig/release-pom.xml mule/release-pom.xml mule/advertising/release-pom.xml mule/button-config/release-pom.xml mule/film/release-pom.xml mule/hospediacard/release-pom.xml mule/location/release-pom.xml mule/profile/release-pom.xml mule/proxy/release-pom.xml mule/rental/release-pom.xml mule/service/release-pom.xml mule/smartcard/release-pom.xml mule/startup/release-pom.xml mule/terminaluimenu/release-pom.xml mule/tv/release-pom.xml mule/upsell/release-pom.xml mule/urlconfig/release-pom.xml

This doesn't work for my setup because each directory is a git submodule so must be run separately, it looks to me like it's simply ignoring the commitByProject setting, but the docs (http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html) list it as being a supported property since 2.0-beta5. I've marked this as a blocker because I wanted to use the release-pom.xml and I have no way to generate them now (since the -DgenerateReleasePoms option on the release:prepare goal seems to have been deprecated).

  2. Text File
    MNG-726-maven-release-manager.patch
    30/Apr/13 5:49 AM
    50 kB
    sital anadkat
  3. Text File
    MNG-726-maven-scm-provider-gitexe.patch
    30/Apr/13 5:49 AM
    10 kB
    sital anadkat
  4. Text File
    patched_output.txt
    30/Apr/13 5:49 AM
    21 kB
    sital anadkat
  5. Text File
    pre_patched_output.txt
    30/Apr/13 5:49 AM
    8 kB
    sital anadkat

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Robert Scholte added a comment -

Is this still happening with version 2.3.1?
A quick scan over the code tells me that a pom.xml and optional release-pom.xml should be committed at once when commitByProject is activated.
I can't see during which release-phase this commit is happening, so could you add more (debug)-logging?

Show
Robert Scholte added a comment - Is this still happening with version 2.3.1? A quick scan over the code tells me that a pom.xml and optional release-pom.xml should be committed at once when commitByProject is activated. I can't see during which release-phase this commit is happening, so could you add more (debug)-logging?
Hide
Permalink
sital anadkat added a comment -

Hi , I created a local fix for a similar issue with maven-release-plugin 2.4 (windows) and git.

scenario:
I want to use maven multi-module configuration where the modules are from different git repositories.
To do this I think we should be able to use git submodules functionality.
to inform the plugin that each module should be treated as its own repo, I use the commitByProject=true

the example scenario is in the zip file bug-726-scenario.zip
I have a parent pom (parent) and a module child (git submodule)
I execute the following command : mvn --batch-mode release:clean release:prepare release:perform

the release plugin fails at the prepare stage (sample below)

**********************failure********************************************************************************
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on project dummy_parent: Unable to commit files
[ERROR] Provider message:
[ERROR] The git-push command failed.
[ERROR] Command output:
[ERROR] To file:///C:/eclipse/workspace17.2/repos/parent.git
[ERROR] ! [rejected] master -> master (non-fast-forward)
[ERROR] error: failed to push some refs to 'file:///C:/eclipse/workspace17.2/repos/parent.git'
[ERROR] hint: Updates were rejected because the tip of your current branch is behind
[ERROR] hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
[ERROR] hint: before pushing again.
[ERROR] hint: See the 'Note about fast-forwards' in 'git push --help' for details.
******************************************************************************************
essentially , the release logic is treating all the modules as part of the same scm repository.

If you apply my patches (both maven-scm-provider-gitexe and maven-release-manager), the prepare and perform should work without error.

Attached are the two patches: one for maven-scm-provider-gitexe and one for maven-release-manager , two outputs (pre_patched_output.txt , patched_output.txt)

In order to test this out for yourself:
1. you will need to change the absolute path of the parent and child repositories.
To do this update the <repoDir> property in the parent pom and commit the changes. I could not find an easier method to demo this scenario as the maven release plugin itself removes any references to the '..' syntax so it is not possible to use relative urls for the scm details.

2.alternatively , you can inspect the unit tests included in the patches.

please note: the key drawback of using git submodules is that submodules are recorded as the EXACT commit they are at. It is not possible to record a submodule at master (or other symbolic tag). So, to solve this problem, the following command is issued: 'git submodule foreach git checkout <tag> ' during the perform stage. If there are no submodule, this has no detrimental effects.

many thanks,

Joe Boggs

Show
sital anadkat added a comment - Hi , I created a local fix for a similar issue with maven-release-plugin 2.4 (windows) and git. scenario: I want to use maven multi-module configuration where the modules are from different git repositories. To do this I think we should be able to use git submodules functionality. to inform the plugin that each module should be treated as its own repo, I use the commitByProject=true the example scenario is in the zip file bug-726-scenario.zip I have a parent pom (parent) and a module child (git submodule) I execute the following command : mvn --batch-mode release:clean release:prepare release:perform the release plugin fails at the prepare stage (sample below) ********************** failure ******************************************************************************** [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on project dummy_parent: Unable to commit files [ERROR] Provider message: [ERROR] The git-push command failed. [ERROR] Command output: [ERROR] To file:///C:/eclipse/workspace17.2/repos/parent.git [ERROR] ! [rejected] master -> master (non-fast-forward) [ERROR] error: failed to push some refs to 'file:///C:/eclipse/workspace17.2/repos/parent.git' [ERROR] hint: Updates were rejected because the tip of your current branch is behind [ERROR] hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') [ERROR] hint: before pushing again. [ERROR] hint: See the 'Note about fast-forwards' in 'git push --help' for details. ****************************************************************************************** essentially , the release logic is treating all the modules as part of the same scm repository. If you apply my patches (both maven-scm-provider-gitexe and maven-release-manager), the prepare and perform should work without error. Attached are the two patches: one for maven-scm-provider-gitexe and one for maven-release-manager , two outputs (pre_patched_output.txt , patched_output.txt) In order to test this out for yourself: 1. you will need to change the absolute path of the parent and child repositories. To do this update the <repoDir> property in the parent pom and commit the changes. I could not find an easier method to demo this scenario as the maven release plugin itself removes any references to the '..' syntax so it is not possible to use relative urls for the scm details. 2.alternatively , you can inspect the unit tests included in the patches. please note: the key drawback of using git submodules is that submodules are recorded as the EXACT commit they are at. It is not possible to record a submodule at master (or other symbolic tag). So, to solve this problem, the following command is issued: 'git submodule foreach git checkout <tag> ' during the perform stage. If there are no submodule, this has no detrimental effects. many thanks, Joe Boggs

People

  • Assignee:
    Unassigned
    Reporter:
    Dave Fennell
Vote (0)
Watch (2)

Dates

  • Created:
    Updated: