[jira] [Created] (MRELEASE-982) Wrong log message when setting suppressCommitBeforeTagOrBranch to true
Stefan Eder created MRELEASE-982:
Summary: Wrong log message when setting
suppressCommitBeforeTagOrBranch to true
Key: MRELEASE-982
URL: https://issues.apache.org/jira/browse/MRELEASE-982
Project: Maven Release Plugin
Issue Type: Bug
Affects Versions: 2.5, 2.4, 2.3
Reporter: Stefan Eder
Priority: Trivial
When setting {{suppressCommitBeforeTagOrBranch}} to {{true}} it actually logs
the following:
{noformat}
[INFO] Modified POMs are not committed because suppressCommitBeforeTagOrBranch
is set to false.
{noformat}
The "error" in this case seems to be a misinterpreted {{else}} clause in the
code of [ScmCommitPreparationPhase.java (line
62)|http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/ScmCommitPreparationPhase.java?view=markup#l62].
This is a minor annoyance when trying to find the cause of a released pom not
being updated in the VCS' tag and seeing this paradox message in the log file.
Actually, the [patch in issue
MVN-745|https://issues.apache.org/jira/secure/attachment/12718278/maven-release-manager.patch]
provided by my doppelganger [~seder] would fix this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-5208) Parallel (-T option) multi module build fires wrong project failed event
[ https://jira.codehaus.org/browse/MNG-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=314895#comment-314895 ] Stefan Eder commented on MNG-5208: -- No problem. Used a homemade version of Maven 3.0.3 for Jenkins in the meantime. Nevertheless looking forward to not having to patch the 3.1 version. ;) Parallel (-T option) multi module build fires wrong project failed event -- Key: MNG-5208 URL: https://jira.codehaus.org/browse/MNG-5208 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0.3 Environment: Maven 3.0.3 (+ Jenkins 1.430) Reporter: Stefan Eder Assignee: Kristian Rosenvold Fix For: 3.1.0 Attachments: maven-core.patch It seems that a parallel multi module build reports the wrong failed module to an event spy. Interestingly the reactor summary shows the right one but I imho the event for the listeners/spys is fired in a wrong fashion. Let's assume the following scenario: * Master ** M1 ** M2 * M1 and M2 will be built parallel * M2 will fail because of a compilation error The events fired for this small scenario will look like this (simplified): # projectStarted(Master) # projectSucceeded(Master) # projectStarted(M1) # projectStarted(M2) # projectFailed(Master) In my opinion the last event should be fired with M2, because this is the module that actually fails. The code where this happens can be found here: http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0.3/maven-core/src/main/java/org/apache/maven/lifecycle/internal/BuilderCommon.java?view=markup (@handleBuildError():137) http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0.3/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilder.java?view=markup (@buildProject():95) So probably it is not right that the rootSession is used in the fire event statement (at least that seems to confuse Jenkins), or am I mistaken? I almost forgot to mention: When a serial build is started then the last event would be projectFailed(M2). For the curious this is the issue I opened (and closed) @Jenkins JIRA: https://issues.jenkins-ci.org/browse/JENKINS-11869 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-745) Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching.
[ https://jira.codehaus.org/browse/MRELEASE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Eder updated MRELEASE-745: - Attachment: maven-release-manager.patch I switched the phase scm-commit-release with scm-commit-development in components-fragment.xml and now it works. The main difference between those to phases is, that scm-commit-release only uses suppressCommitBeforeBranch to determine whether to check in or not. Whereas scm-commit-development uses updateWorkingCopyVersions. Therefore I think scm-commit-development is the right phase here. Additionally I provided a patch file which changes the phase and the message mentioned in my last post. Can't guarantee that this is 100% right but it works for me. Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching. - Key: MRELEASE-745 URL: https://jira.codehaus.org/browse/MRELEASE-745 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.1 Environment: Windows (7, Server 2003), Maven 2.2.1, Jenkins 1.420 Reporter: Chris Wilton Attachments: maven-release-manager.patch I have a multi-module maven project. I create 'release branches' for testing, then once testing is complete, I create the release tag from the branch. In order to work around the subversion 1.5.x problem (http://jira.codehaus.org/browse/SCM-515) I have the following properties set: suppressCommitBeforeBranch=true suppressCommitBeforeTag=true remoteTagging=false Implicit (as default) values are: updateBranchVersions=false updateWorkingCopyVersions=true The intention is to create a branch with the same pom versions as the trunk, without committing any modifications to the trunk (in order to avoid the SCM section for the branch ending up in the trunk poms), then to bump up the trunk versions and commit them. But although the trunk pom versions are modified, they are not committed. I want commit suppressed BEFORE branching, not AFTER, else I have to run release:update-versions afterwards and perform a manual commit, to bump up the trunk versions. I should mention that this is being run as a (parameterized) Jenkins task, so it is not simply a case of manually committing my working copy to the trunk after the branching process is complete. Am I doing something wrong? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-745) Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching.
[ https://jira.codehaus.org/browse/MRELEASE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=295754#comment-295754 ] Stefan Eder commented on MRELEASE-745: -- We experience the same problem with Maven 3.0.3 and release-plugin 2.2.2. Same properties (except for suppressCommitBeforeTag=true). The local working copy is modified but not committed. So either the suppressCommitBeforeBranch is handled in a wrong way or the name of the property is misleading. In the meantime (since we use Jenkins), we implemented an additional svn CLI step to commit the changes made to the working copy. Additionally it is also possible to set suppressCommitBeforeBranch=true. But this leads to a (probably unwanted) commit of modified Poms before the branch is created. Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching. - Key: MRELEASE-745 URL: https://jira.codehaus.org/browse/MRELEASE-745 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.1 Environment: Windows (7, Server 2003), Maven 2.2.1, Jenkins 1.420 Reporter: Chris Wilton I have a multi-module maven project. I create 'release branches' for testing, then once testing is complete, I create the release tag from the branch. In order to work around the subversion 1.5.x problem (http://jira.codehaus.org/browse/SCM-515) I have the following properties set: suppressCommitBeforeBranch=true suppressCommitBeforeTag=true remoteTagging=false Implicit (as default) values are: updateBranchVersions=false updateWorkingCopyVersions=true The intention is to create a branch with the same pom versions as the trunk, without committing any modifications to the trunk (in order to avoid the SCM section for the branch ending up in the trunk poms), then to bump up the trunk versions and commit them. But although the trunk pom versions are modified, they are not committed. I want commit suppressed BEFORE branching, not AFTER, else I have to run release:update-versions afterwards and perform a manual commit, to bump up the trunk versions. I should mention that this is being run as a (parameterized) Jenkins task, so it is not simply a case of manually committing my working copy to the trunk after the branching process is complete. Am I doing something wrong? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-745) Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching.
[ https://jira.codehaus.org/browse/MRELEASE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=295754#comment-295754 ] Stefan Eder edited comment on MRELEASE-745 at 4/4/12 7:57 AM: -- We experience the same problem with Maven 3.0.3 and release-plugin 2.2.2. Same properties (except for suppressCommitBeforeTag=true). The local working copy is modified but not committed. So either the suppressCommitBeforeBranch is handled in a wrong way or the name of the property is misleading. In the meantime (since we use Jenkins), we implemented an additional svn CLI step to commit the changes made to the working copy. Additionally it is also possible to set suppressCommitBeforeBranch=false. But this leads to a (probably unwanted) commit of modified Poms before the branch is created. was (Author: seder): We experience the same problem with Maven 3.0.3 and release-plugin 2.2.2. Same properties (except for suppressCommitBeforeTag=true). The local working copy is modified but not committed. So either the suppressCommitBeforeBranch is handled in a wrong way or the name of the property is misleading. In the meantime (since we use Jenkins), we implemented an additional svn CLI step to commit the changes made to the working copy. Additionally it is also possible to set suppressCommitBeforeBranch=true. But this leads to a (probably unwanted) commit of modified Poms before the branch is created. Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching. - Key: MRELEASE-745 URL: https://jira.codehaus.org/browse/MRELEASE-745 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.1 Environment: Windows (7, Server 2003), Maven 2.2.1, Jenkins 1.420 Reporter: Chris Wilton I have a multi-module maven project. I create 'release branches' for testing, then once testing is complete, I create the release tag from the branch. In order to work around the subversion 1.5.x problem (http://jira.codehaus.org/browse/SCM-515) I have the following properties set: suppressCommitBeforeBranch=true suppressCommitBeforeTag=true remoteTagging=false Implicit (as default) values are: updateBranchVersions=false updateWorkingCopyVersions=true The intention is to create a branch with the same pom versions as the trunk, without committing any modifications to the trunk (in order to avoid the SCM section for the branch ending up in the trunk poms), then to bump up the trunk versions and commit them. But although the trunk pom versions are modified, they are not committed. I want commit suppressed BEFORE branching, not AFTER, else I have to run release:update-versions afterwards and perform a manual commit, to bump up the trunk versions. I should mention that this is being run as a (parameterized) Jenkins task, so it is not simply a case of manually committing my working copy to the trunk after the branching process is complete. Am I doing something wrong? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-745) Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching.
[ https://jira.codehaus.org/browse/MRELEASE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=295758#comment-295758 ] Stefan Eder commented on MRELEASE-745: -- After I searched the code for the error message (Modified POMs are not committed because suppressCommitBeforeTagOrBranch is set to false) which is displayed when executing release:branch with suppressCommitBeforeTag=true I thought, maybe the wrong Phase is used in thiscase? ScmCommitPreparationPhase seems to be used and ScmCommitDevelopmentPhase should be used? But that's just a hunch and I did not do any debugging right now. Maybe when I have some spare time. Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching. - Key: MRELEASE-745 URL: https://jira.codehaus.org/browse/MRELEASE-745 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.1 Environment: Windows (7, Server 2003), Maven 2.2.1, Jenkins 1.420 Reporter: Chris Wilton I have a multi-module maven project. I create 'release branches' for testing, then once testing is complete, I create the release tag from the branch. In order to work around the subversion 1.5.x problem (http://jira.codehaus.org/browse/SCM-515) I have the following properties set: suppressCommitBeforeBranch=true suppressCommitBeforeTag=true remoteTagging=false Implicit (as default) values are: updateBranchVersions=false updateWorkingCopyVersions=true The intention is to create a branch with the same pom versions as the trunk, without committing any modifications to the trunk (in order to avoid the SCM section for the branch ending up in the trunk poms), then to bump up the trunk versions and commit them. But although the trunk pom versions are modified, they are not committed. I want commit suppressed BEFORE branching, not AFTER, else I have to run release:update-versions afterwards and perform a manual commit, to bump up the trunk versions. I should mention that this is being run as a (parameterized) Jenkins task, so it is not simply a case of manually committing my working copy to the trunk after the branching process is complete. Am I doing something wrong? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-745) Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching.
[ https://jira.codehaus.org/browse/MRELEASE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=295758#comment-295758 ] Stefan Eder edited comment on MRELEASE-745 at 4/4/12 8:32 AM: -- After I searched the code for the error message (Modified POMs are not committed because suppressCommitBeforeTagOrBranch is set to false) which is displayed when executing release:branch with suppressCommitBeforeTag=true I thought, maybe the wrong Phase is used in thiscase? ScmCommitPreparationPhase seems to be used and ScmCommitDevelopmentPhase should be used? But that's just a hunch and I did not do any debugging right now. Maybe when I have some spare time. By the way... IMHO the message should read Modified POMs are not committed because suppressCommitBeforeTagOrBranch is set to TRUE because it's displayed when condition releaseDescriptor.isSuppressCommitBeforeTagOrBranch() is met... was (Author: seder): After I searched the code for the error message (Modified POMs are not committed because suppressCommitBeforeTagOrBranch is set to false) which is displayed when executing release:branch with suppressCommitBeforeTag=true I thought, maybe the wrong Phase is used in thiscase? ScmCommitPreparationPhase seems to be used and ScmCommitDevelopmentPhase should be used? But that's just a hunch and I did not do any debugging right now. Maybe when I have some spare time. Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching. - Key: MRELEASE-745 URL: https://jira.codehaus.org/browse/MRELEASE-745 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.1 Environment: Windows (7, Server 2003), Maven 2.2.1, Jenkins 1.420 Reporter: Chris Wilton I have a multi-module maven project. I create 'release branches' for testing, then once testing is complete, I create the release tag from the branch. In order to work around the subversion 1.5.x problem (http://jira.codehaus.org/browse/SCM-515) I have the following properties set: suppressCommitBeforeBranch=true suppressCommitBeforeTag=true remoteTagging=false Implicit (as default) values are: updateBranchVersions=false updateWorkingCopyVersions=true The intention is to create a branch with the same pom versions as the trunk, without committing any modifications to the trunk (in order to avoid the SCM section for the branch ending up in the trunk poms), then to bump up the trunk versions and commit them. But although the trunk pom versions are modified, they are not committed. I want commit suppressed BEFORE branching, not AFTER, else I have to run release:update-versions afterwards and perform a manual commit, to bump up the trunk versions. I should mention that this is being run as a (parameterized) Jenkins task, so it is not simply a case of manually committing my working copy to the trunk after the branching process is complete. Am I doing something wrong? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-745) Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching.
[ https://jira.codehaus.org/browse/MRELEASE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=295758#comment-295758 ] Stefan Eder edited comment on MRELEASE-745 at 4/4/12 8:38 AM: -- After I searched the code for the error message (Modified POMs are not committed because suppressCommitBeforeTagOrBranch is set to false) which is displayed when executing release:branch with suppressCommitBeforeTag=true I thought, maybe the wrong Phase is used in this case? ScmCommitPreparationPhase seems to be used and ScmCommitDevelopmentPhase should be used? But that's just a hunch and I did not do any debugging right now. Maybe when I have some spare time. By the way... IMHO the message should read Modified POMs are not committed because suppressCommitBeforeTagOrBranch is set to TRUE because it's displayed when condition releaseDescriptor.isSuppressCommitBeforeTagOrBranch() is met... was (Author: seder): After I searched the code for the error message (Modified POMs are not committed because suppressCommitBeforeTagOrBranch is set to false) which is displayed when executing release:branch with suppressCommitBeforeTag=true I thought, maybe the wrong Phase is used in thiscase? ScmCommitPreparationPhase seems to be used and ScmCommitDevelopmentPhase should be used? But that's just a hunch and I did not do any debugging right now. Maybe when I have some spare time. By the way... IMHO the message should read Modified POMs are not committed because suppressCommitBeforeTagOrBranch is set to TRUE because it's displayed when condition releaseDescriptor.isSuppressCommitBeforeTagOrBranch() is met... Property suppressCommitBeforeBranch also suppresses trunk commit AFTER branching. - Key: MRELEASE-745 URL: https://jira.codehaus.org/browse/MRELEASE-745 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.1 Environment: Windows (7, Server 2003), Maven 2.2.1, Jenkins 1.420 Reporter: Chris Wilton I have a multi-module maven project. I create 'release branches' for testing, then once testing is complete, I create the release tag from the branch. In order to work around the subversion 1.5.x problem (http://jira.codehaus.org/browse/SCM-515) I have the following properties set: suppressCommitBeforeBranch=true suppressCommitBeforeTag=true remoteTagging=false Implicit (as default) values are: updateBranchVersions=false updateWorkingCopyVersions=true The intention is to create a branch with the same pom versions as the trunk, without committing any modifications to the trunk (in order to avoid the SCM section for the branch ending up in the trunk poms), then to bump up the trunk versions and commit them. But although the trunk pom versions are modified, they are not committed. I want commit suppressed BEFORE branching, not AFTER, else I have to run release:update-versions afterwards and perform a manual commit, to bump up the trunk versions. I should mention that this is being run as a (parameterized) Jenkins task, so it is not simply a case of manually committing my working copy to the trunk after the branching process is complete. Am I doing something wrong? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5208) Parallel (-T option) multi module build fires wrong project failed event
[ https://jira.codehaus.org/browse/MNG-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Eder updated MNG-5208: - Attachment: maven-core.patch This is how I solved the problem (it seems to work for me). Maybe some interested Maven developer could review it and commit it. Parallel (-T option) multi module build fires wrong project failed event -- Key: MNG-5208 URL: https://jira.codehaus.org/browse/MNG-5208 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0.3 Environment: Maven 3.0.3 (+ Jenkins 1.430) Reporter: Stefan Eder Attachments: maven-core.patch It seems that a parallel multi module build reports the wrong failed module to an event spy. Interestingly the reactor summary shows the right one but I imho the event for the listeners/spys is fired in a wrong fashion. Let's assume the following scenario: * Master ** M1 ** M2 * M1 and M2 will be built parallel * M2 will fail because of a compilation error The events fired for this small scenario will look like this (simplified): # projectStarted(Master) # projectSucceeded(Master) # projectStarted(M1) # projectStarted(M2) # projectFailed(Master) In my opinion the last event should be fired with M2, because this is the module that actually fails. The code where this happens can be found here: http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0.3/maven-core/src/main/java/org/apache/maven/lifecycle/internal/BuilderCommon.java?view=markup (@handleBuildError():137) http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0.3/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilder.java?view=markup (@buildProject():95) So probably it is not right that the rootSession is used in the fire event statement (at least that seems to confuse Jenkins), or am I mistaken? I almost forgot to mention: When a serial build is started then the last event would be projectFailed(M2). For the curious this is the issue I opened (and closed) @Jenkins JIRA: https://issues.jenkins-ci.org/browse/JENKINS-11869 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5208) Parallel (-T option) multi module build fires wrong project failed event
Parallel (-T option) multi module build fires wrong project failed event -- Key: MNG-5208 URL: https://jira.codehaus.org/browse/MNG-5208 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0.3 Environment: Maven 3.0.3 (+ Jenkins 1.430) Reporter: Stefan Eder It seems that a parallel multi module build reports the wrong failed module to an event spy. Interestingly the reactor summary shows the right one but I imho the event for the listeners/spys is fired in a wrong fashion. Let's assume the following scenario: * Master ** M1 ** M2 * M1 and M2 will be built parallel * M2 will fail because of a compilation error The events fired for this small scenario will look like this (simplified): # projectStarted(Master) # projectSucceeded(Master) # projectStarted(M1) # projectStarted(M2) # projectFailed(Master) In my opinion the last event should be fired with M2, because this is the module that actually fails. The code where this happens can be found here: http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0.3/maven-core/src/main/java/org/apache/maven/lifecycle/internal/BuilderCommon.java?view=markup (@handleBuildError():137) http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0.3/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilder.java?view=markup (@buildProject():95) So probably it is not right that the rootSession is used in the fire event statement (at least that seems to confuse Jenkins), or am I mistaken? I almost forgot to mention: When a serial build is started then the last event would be projectFailed(M2). For the curious this is the issue I opened (and closed) @Jenkins JIRA: https://issues.jenkins-ci.org/browse/JENKINS-11869 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
