[jira] [Commented] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure
[
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17009517#comment-17009517
]
Paul Millar commented on SUREFIRE-1719:
---
Hi Tibor,
I've tested the 3.0.0-SNAPSHOT and it works perfectly.
Thanks for all you help!
Paul.
> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2,
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3,
> unit tests started to fail with the message "ExecutionException The forked VM
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{ org.apache.maven.plugins}}
> {{ maven-surefire-plugin}}
> {{ }}
> {{ }}
> {{ **/*Test.class}}
> {{ **/*Tests.class}}
> {{ }}
> {{ }}
> {{ 1C}}
> {{ false}}
> {{ }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the
> problem appear 6 out of 10 times when running the above mvn command. There is
> (apparently) little that seems to influence whether the build will succeed or
> fail.
> [I've attached the complete output from running the above mvn command, both
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores.
> Our build machine has 24 cores, and I've seen a report of a similar problem
> where building dCache on a 48 core machine. On the other side, I have been
> unable to reproduce the problem with my desktop machine (8 core) or on my
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on
> a machine with a small number of cores. However, I've noticed that, on an 8
> core machine, increasing the forkCount does not actually result in that many
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood
> of a problem below 10% (0 failures with 10 builds) on our build machine. On
> this machine, the default configuration would try to run 24 JVM instances
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building
> with surefire v2.19.1, the above mvn command is always successful on our
> build machine. Building with surefire v2.20 results in intermittent failures
> (~60% failure rate).
> Using git bisection (and with the criterion for "good" as zero failures in 10
> build attempts), I was able to determine that commit da7ff6aa2 "SUREFIRE-1342
> Acknowledge normal exit of JVM and drain shared memory between processes" is
> the first commit where surefire has this intermittent failure behaviour.
> From a causal scan through the patch, my guess is that the BYE_ACK support it
> introduces is somehow racy (for example, reading or updating a field-member
> outside of a monitor) and problems are triggered if there are a large number
> of JVMs exiting concurrently. So, with increased number of concurrent JVMs
> there is an increased risk of a thread loosing the race, and so triggering
> this error.
> Such a problem would be consistent with observed behaviour. However, I don't
> have any strong evidence that this is what is happening.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure
[
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978189#comment-16978189
]
Paul Millar commented on SUREFIRE-1719:
---
Hi Tibor,
Good to hear you've found the problem.
Is there something I can do to confirm it? For example, if you have a private
branch of surefire with additional logging, I could build that version, deploy
it as a snapshot in our private nexus and exercise building dCache.
> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2,
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Priority: Major
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3,
> unit tests started to fail with the message "ExecutionException The forked VM
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{ org.apache.maven.plugins}}
> {{ maven-surefire-plugin}}
> {{ }}
> {{ }}
> {{ **/*Test.class}}
> {{ **/*Tests.class}}
> {{ }}
> {{ }}
> {{ 1C}}
> {{ false}}
> {{ }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the
> problem appear 6 out of 10 times when running the above mvn command. There is
> (apparently) little that seems to influence whether the build will succeed or
> fail.
> [I've attached the complete output from running the above mvn command, both
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores.
> Our build machine has 24 cores, and I've seen a report of a similar problem
> where building dCache on a 48 core machine. On the other side, I have been
> unable to reproduce the problem with my desktop machine (8 core) or on my
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on
> a machine with a small number of cores. However, I've noticed that, on an 8
> core machine, increasing the forkCount does not actually result in that many
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood
> of a problem below 10% (0 failures with 10 builds) on our build machine. On
> this machine, the default configuration would try to run 24 JVM instances
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building
> with surefire v2.19.1, the above mvn command is always successful on our
> build machine. Building with surefire v2.20 results in intermittent failures
> (~60% failure rate).
> Using git bisection (and with the criterion for "good" as zero failures in 10
> build attempts), I was able to determine that commit da7ff6aa2 "SUREFIRE-1342
> Acknowledge normal exit of JVM and drain shared memory between processes" is
> the first commit where surefire has this intermittent failure behaviour.
> From a causal scan through the patch, my guess is that the BYE_ACK support it
> introduces is somehow racy (for example, reading or updating a field-member
> outside of a monitor) and problems are triggered if there are a large number
> of JVMs exiting concurrently. So, with increased number of concurrent JVMs
> there is an increased risk of a thread loosing the race, and so triggering
> this error.
> Such a problem would be consistent with observed behaviour. However, I don't
> have any strong evidence that this is what is happening.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure
[
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16976582#comment-16976582
]
Paul Millar commented on SUREFIRE-1719:
---
Hi Tibor,
Just a quick update.
I've been able to reproduce the problem with Surefire v3.0.0-M4.
Running the same command (mvn -am -pl modules/common clean package), the
unit-tests failed with a similar output as reported above. I attempted
building with v3.0.0-M4 ten times and all attempts failed. This is seemingly a
worse failure rate than described above; although, if this is a race-condition,
external factors may be having an impact.
This is building on a 24-core machine. As before, updating the pom.xml to set
forkCount from "1C" (== 24) to "6" results in all ten build attempts passing.
Despite the error message mentioning *.dump and *.dumpstream files, I see no
such files in the target/surefire-reports directory. I also checked /tmp and
/var/tmp: no such files are there, either.
I'm not sure which options I should add to avoid GC logging: I believe this is
off by default. If you have a concrete suggestion, I'd be happy to try it out.
I'm using OpenJDK "v1.8.0_232" JRE "1.8.0_232-b09", OpenJDK 64-bit server
(build 25.232-b09, mixed mode).
One additional observation. The "modules/common" module has 35 test classes.
For each of the 35 classes, I see maven logs that is is running that class
(lines like "[INFO] Running org.dcache"). However, there are *fewer*
logged test result lines (lines like "[INFO] Tests run: x, Failures: x, Errors:
x, "). So, maven/surefire is not logging a result line for some test
classes, despite (apparently) starting that JVM.
The specific "missing" results changes from run to run. The precise number of
missing test class results also changes: sometimes only one class is missing,
sometimes it's two classes.
For each test class with a test result line, there is a corresponding .txt and
.xml file in results/surefire-reports directory. However, the test classes
that have no test result line also have no corresponding .txt or .xml file.
HTH,
Paul.
> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2,
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Priority: Major
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3,
> unit tests started to fail with the message "ExecutionException The forked VM
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{ org.apache.maven.plugins}}
> {{ maven-surefire-plugin}}
> {{ }}
> {{ }}
> {{ **/*Test.class}}
> {{ **/*Tests.class}}
> {{ }}
> {{ }}
> {{ 1C}}
> {{ false}}
> {{ }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the
> problem appear 6 out of 10 times when running the above mvn command. There is
> (apparently) little that seems to influence whether the build will succeed or
> fail.
> [I've attached the complete output from running the above mvn command, both
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores.
> Our build machine has 24 cores, and I've seen a report of a similar problem
> where building dCache on a 48 core machine. On the other side, I have been
> unable to reproduce the problem with my desktop machine (8 core) or on my
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on
> a machine with a small number of cores. However, I've noticed that, on an 8
> core machine, increasing the forkCount does not actually result in that many
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood
> of a problem below 10% (0 failures with 10 builds) on our build machine. On
> this machine, the default configuration would try to run 24 JVM instances
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building
> with surefire v2.19.1, the above mvn command is
[jira] [Created] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure
Paul Millar created SUREFIRE-1719:
-
Summary: Race condition results in "VM crash or System.exit
called?" failure
Key: SUREFIRE-1719
URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 3.0.0-M3, 3.0.0-M1, 3.0.0-M2, 2.22.2, 2.22.1, 2.22.0,
2.21.0, 2.20.1, 2.20
Reporter: Paul Millar
Attachments: build-error-debug.out, build.out, pom.xml
After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3, unit
tests started to fail with the message "ExecutionException The forked VM
terminated without properly saying goodbye. VM crash or System.exit called?"
For reference, the command I am using to verify this problem is "mvn -am -pl
modules/common clean package" and the surefire configuration is:
{{}}
{{ org.apache.maven.plugins}}
{{ maven-surefire-plugin}}
{{ }}
{{ }}
{{ **/*Test.class}}
{{ **/*Tests.class}}
{{ }}
{{ }}
{{ 1C}}
{{ false}}
{{ }}
{{ }}
[The complete pom.xml is attached.]
This problem is not always present. On our build machine, I've seen the problem
appear 6 out of 10 times when running the above mvn command. There is
(apparently) little that seems to influence whether the build will succeed or
fail.
[I've attached the complete output from running the above mvn command, both the
normal output and including the -e -X options.]
The problem seems to appear only on machines with a "large" number of cores.
Our build machine has 24 cores, and I've seen a report of a similar problem
where building dCache on a 48 core machine. On the other side, I have been
unable to reproduce the problem with my desktop machine (8 core) or on my
laptop (4 cores).
What seems to matter is the number of actually running JVM instances.
I have not been able to reproduce the problem by increasing the forkCount on a
machine with a small number of cores. However, I've noticed that, on an 8 core
machine, increasing the forkCount does not actually result in that many more
JVM instances running.
Similarly, experience shows that reducing the number of concurrent JVM
instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood
of a problem below 10% (0 failures with 10 builds) on our build machine. On
this machine, the default configuration would try to run 24 JVM instances
concurrently (forkCount of "1C" on a 24 core machine).
The problem appears to have been introduced in surefire v2.20. When building
with surefire v2.19.1, the above mvn command is always successful on our build
machine. Building with surefire v2.20 results in intermittent failures (~60%
failure rate).
Using git bisection (and with the criterion for "good" as zero failures in 10
build attempts), I was able to determine that commit da7ff6aa2 "SUREFIRE-1342
Acknowledge normal exit of JVM and drain shared memory between processes" is
the first commit where surefire has this intermittent failure behaviour.
>From a causal scan through the patch, my guess is that the BYE_ACK support it
>introduces is somehow racy (for example, reading or updating a field-member
>outside of a monitor) and problems are triggered if there are a large number
>of JVMs exiting concurrently. So, with increased number of concurrent JVMs
>there is an increased risk of a thread loosing the race, and so triggering
>this error.
Such a problem would be consistent with observed behaviour. However, I don't
have any strong evidence that this is what is happening.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-334) Missing configuration documentation
[ https://issues.apache.org/jira/browse/MCOMPILER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16426579#comment-16426579 ] Paul Millar commented on MCOMPILER-334: --- Yes, that's exactly the information I was after. Sorry, it was completely unclear to me that the configuration options are goal-specific. Options appear to be mostly specified at the generic level (i.e., not within goal-specific execution blocks). For example, almost all the given examples are like this. If I may suggest, perhaps dropping a throw-away sentence in the usage page might help point other similarly confused people in the right direction. In any case, feel free to close this ticket. > Missing configuration documentation > --- > > Key: MCOMPILER-334 > URL: https://issues.apache.org/jira/browse/MCOMPILER-334 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.5.1 >Reporter: Paul Millar >Priority: Minor > > The [Usage > page|https://maven.apache.org/plugins/maven-compiler-plugin/usage.html] > should provide information on how to use this plugin. However, there is > almost no mention of the available configuration options on this page. > The navigation panel provides links to several example scenarios: [Compile > Using A Different > JDK|https://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html], > [Compile Using -source and -target javac > Options|https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html], > etc. These are (no doubt) very helpful for people solving those specific > problems. However, there is apparently no page that provides the > authoritative description of available configuration options. > Please add a page that provides a list of available configuration options, > their expected formats, the default value (if that option is not specified), > and the semantics if the value is specified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MCOMPILER-334) Missing configuration documentation
Paul Millar created MCOMPILER-334: - Summary: Missing configuration documentation Key: MCOMPILER-334 URL: https://issues.apache.org/jira/browse/MCOMPILER-334 Project: Maven Compiler Plugin Issue Type: Improvement Affects Versions: 3.5.1 Reporter: Paul Millar The [Usage page|https://maven.apache.org/plugins/maven-compiler-plugin/usage.html] should provide information on how to use this plugin. However, there is almost no mention of the available configuration options on this page. The navigation panel provides links to several example scenarios: [Compile Using A Different JDK|https://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html], [Compile Using -source and -target javac Options|https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html], etc. These are (no doubt) very helpful for people solving those specific problems. However, there is apparently no page that provides the authoritative description of available configuration options. Please add a page that provides a list of available configuration options, their expected formats, the default value (if that option is not specified), and the semantics if the value is specified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] (MASSEMBLY-681) plugin ignores empty finalName and uses default value
[
https://jira.codehaus.org/browse/MASSEMBLY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340228#comment-340228
]
Paul Millar commented on MASSEMBLY-681:
---
If I've understood you correctly, maven mojo XML parser simply ignores empty
elements. If so, this sounds like a bug as an empty element is both valid and
distinct from that element being missing.
To me, introducing a noFinalName flag looks like a work-around for this
XML-parser bug. As the problem isn't urgent (at least, for me), perhaps it
would be better to fix the mojo XML parser so empty XML elements are not
ignored.
> plugin ignores empty finalName and uses default value
> -
>
> Key: MASSEMBLY-681
> URL: https://jira.codehaus.org/browse/MASSEMBLY-681
> Project: Maven Assembly Plugin
> Issue Type: Wish
>Affects Versions: 2.4
>Reporter: Paul Millar
>Priority: Minor
>
> When used in the 'dir' format, I would argue that an empty finalName is
> reasonable.
> For example, I would expect the following configuration, with the 'dir'
> format, to output the assembled files in ${foo.baseDirectory}
>
>
> src/main/assembly/foo.xml
>
> ${foo.baseDirectory}
>
>
> The actual behaviour is to silently ignore the configured empty finalName and
> use the default finalName value, which is append this to the outputDirectory.
> Arguably there are two bugs here:
> finalName is silently ignored (if this is invalid, it should report an
> error)
> the empty finalName is not honoured.
> Specify '.' as the finalName (.) seems to work as a
> work-around, at least for unix-like systems.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-681) plugin ignores empty finalName and uses default value
Paul Millar created MASSEMBLY-681:
-
Summary: plugin ignores empty finalName and uses default value
Key: MASSEMBLY-681
URL: https://jira.codehaus.org/browse/MASSEMBLY-681
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.4
Reporter: Paul Millar
Priority: Minor
When used in the 'dir' format, I would argue that an empty finalName is
reasonable.
For example, I would expect the following configuration, with the 'dir' format,
to output the assembled files in ${foo.baseDirectory}
src/main/assembly/foo.xml
${foo.baseDirectory}
The actual behaviour is to silently ignore the configured empty finalName and
use the default finalName value, which is append this to the outputDirectory.
Arguably there are two bugs here:
finalName is silently ignored (if this is invalid, it should report an
error)
the empty finalName is not honoured.
Specify '.' as the finalName (.) seems to work as a
work-around, at least for unix-like systems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338692#comment-338692 ] Paul Millar commented on MRELEASE-812: -- Sorry for the noob question, but when will 2.5 be released? [This link|https://jira.codehaus.org/browse/MRELEASE/fixforversion/19017] doesn't seem to contain any release schedule information (or link to any such information). As the 2.5 contains critical bug-fixes, a timely release would be useful. > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.4 >Reporter: Andrei Pozolotin >Assignee: Robert Scholte >Priority: Critical > Fix For: 2.5 > > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338259#comment-338259 ] Paul Millar commented on MRELEASE-812: -- Hit this problem myself (or one like it). The trigger seems to be an upgrade of git from 1.8.5.1 to 1.8.5.2, but I'm still double-checking that. I tried the above work-around posted by Catalin (updating maven-scm version dependency to 1.8.1) but encountered the problem described in SCM 709: support for sub-projects/modules is broken. Is there a way to test SCM 686 and SCM 709 together; e.g., a snapshot or nightly release of maven-scm I could add as a dependency instead of 1.8.1? In SCM 709, they cite a lack of feedback as a reason why progress isn't being made, but it's unclear to me how they expect to receive this feedback if the patch isn't available for testing somewhere. > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.4 >Reporter: Andrei Pozolotin >Priority: Critical > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
