[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] (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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] 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
