[jira] [Commented] (MEAR-171) Full customization of FileNameMapping is needed
[
https://issues.apache.org/jira/browse/MEAR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193988#comment-16193988
]
Hudson commented on MEAR-171:
-
SUCCESS: Integrated in Jenkins build maven-plugins #9148 (See
[https://builds.apache.org/job/maven-plugins/9148/])
[MEAR-171] fixed IT (hboutemy:
[http://svn.apache.org/viewvc/?view=rev=1811279])
* (edit) maven-ear-plugin/pom.xml
* (edit) maven-ear-plugin/src/it/settings.xml
* (edit) maven-ear-plugin/src/it/skinny-wars-timestamp/verify.bsh
> Full customization of FileNameMapping is needed
> ---
>
> Key: MEAR-171
> URL: https://issues.apache.org/jira/browse/MEAR-171
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Darryl L. Miles
>Assignee: Karl Heinz Marbaise
> Fix For: 3.0.0
>
>
> What is the logic with the seemingly non-standard conversion groupId by
> replacing '.' with '-' in the "full" mode ? Surely this mode should have
> been called "full-with-groupId-rewrite".
> The purpose of this decision should have been documented in the code, someone
> needs to do so or make this format obsolete.
> Alternately the field should look at the maven-war-plugin and the ability to
> support mapping like:
> {noformat}
> @{groupId}@.@{artifactId}@@{dashClassifier?}@-@{version}@.@{extension}@
> {noformat}
> Also the $\{project.finalName} and $\{project.name} would be useful (taken
> out of the dependency's own POM, not the EAR project).
> If this unusual replacement of groupId is required, then maybe
> @\{groupIdReplaceDots}@ can be provided.
> The problem is that the names used are IMPORTANT to know and automate because
> it maybe necessary to place them on the Class-Path in MANIFEST.MF files.
> This non-standard choice needs to be explained because it really is
> non-intuitive and there are no other mechanisms across the maven plugins to
> manage and rewrite Class-Path values in accordance with this convention.
> There is on the other hand clear ways to configure a project and decide on
> the output file names on a project by project basis. This is what should be
> the default, what the project itself decided it wanted to be called like
> $\{project.finalName}.
> The Maven documentation should include complete example of this "full"
> behaviour along with explanation of why it is useful to the user.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MSHARED-655) ArtifactInstaller check for integrity of parameters null, empty collection, being a directory
[
https://issues.apache.org/jira/browse/MSHARED-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193910#comment-16193910
]
Hudson commented on MSHARED-655:
SUCCESS: Integrated in Jenkins build maven-shared #3761 (See
[https://builds.apache.org/job/maven-shared/3761/])
[MSHARED-655] fixed UT (hboutemy:
[http://svn.apache.org/viewvc/?view=rev=1811272])
* (edit)
maven-artifact-transfer/src/test/java/org/apache/maven/shared/artifact/install/internal/DefaultArtifactInstallerTest.java
> ArtifactInstaller check for integrity of parameters null, empty collection,
> being a directory
> -
>
> Key: MSHARED-655
> URL: https://issues.apache.org/jira/browse/MSHARED-655
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.9.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-artifact-transfer-1.0.0
>
>
> Currently the interface {{ArtifactInstaller}} contains the two methods:
> {code:java}
> public interface ArtifactInstaller
> {
> void install( ProjectBuildingRequest request, Collection
> mavenArtifacts );
> void install( ProjectBuildingRequest request, File localRepository,
> Collection mavenArtifacts );
> }
> {code}
> We should make sure that {{ProjectBuildRequest}} can't be null. Furthermore
> the {{mavenArtifacts}} should also being checked for {{null}}. We need to
> think if an {{empty}} collection is allowed or not? (I think it should not
> being allowed?)
> Apart from that the {{localRepository}} should be checked for {{null}} and it
> should be checked for being a directory if it is not {{null}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MSHARED-625) Refactored to use 'maven-shared-utils' instead of 'plexus-utils'.
[ https://issues.apache.org/jira/browse/MSHARED-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MSHARED-625. - Resolution: Fixed Assignee: Christian Schulte > Refactored to use 'maven-shared-utils' instead of 'plexus-utils'. > -- > > Key: MSHARED-625 > URL: https://issues.apache.org/jira/browse/MSHARED-625 > Project: Maven Shared Components > Issue Type: Task > Components: maven-invoker >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Trivial > Fix For: maven-invoker-3.0.1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MSHARED-624) Upgrade of maven-shared-utils from 0.8 to 3.2.0.
[ https://issues.apache.org/jira/browse/MSHARED-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MSHARED-624. - Resolution: Fixed Assignee: Christian Schulte > Upgrade of maven-shared-utils from 0.8 to 3.2.0. > > > Key: MSHARED-624 > URL: https://issues.apache.org/jira/browse/MSHARED-624 > Project: Maven Shared Components > Issue Type: Task > Components: maven-verifier >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Trivial > Fix For: maven-verifier-1.7 > > > to benefit from MSHARED-617 MSHARED-618 MSHARED-619 MSHARED-620 MSHARED-621 > MSHARED-622 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1430) Parallel parameterized JUnit test hangs on Linux
[ https://issues.apache.org/jira/browse/SUREFIRE-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1430: --- Fix Version/s: 2.21.1 > Parallel parameterized JUnit test hangs on Linux > > > Key: SUREFIRE-1430 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1430 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.18, 2.18.1, 2.19, 2.19.1, 2.20, 2.20.1 > Environment: Linux/Ubuntu >Reporter: Christian Beikov >Assignee: Tibor Digana > Fix For: 2.21.1 > > > This is a follow up of SUREFIRE-1264. The test case is here: > https://github.com/beikov/surefire-test > The problem is, that a simple parameterized JUnit test hangs when running in > parallel mode on Linux. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (SUREFIRE-1430) Parallel parameterized JUnit test hangs on Linux
[ https://issues.apache.org/jira/browse/SUREFIRE-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1430: -- Assignee: Tibor Digana > Parallel parameterized JUnit test hangs on Linux > > > Key: SUREFIRE-1430 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1430 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.18, 2.18.1, 2.19, 2.19.1, 2.20, 2.20.1 > Environment: Linux/Ubuntu >Reporter: Christian Beikov >Assignee: Tibor Digana > Fix For: 2.21.1 > > > This is a follow up of SUREFIRE-1264. The test case is here: > https://github.com/beikov/surefire-test > The problem is, that a simple parameterized JUnit test hangs when running in > parallel mode on Linux. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SUREFIRE-1430) Parallel parameterized JUnit test hangs on Linux
Christian Beikov created SUREFIRE-1430: -- Summary: Parallel parameterized JUnit test hangs on Linux Key: SUREFIRE-1430 URL: https://issues.apache.org/jira/browse/SUREFIRE-1430 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Affects Versions: 2.20.1, 2.20, 2.19.1, 2.19, 2.18.1, 2.18 Environment: Linux/Ubuntu Reporter: Christian Beikov This is a follow up of SUREFIRE-1264. The test case is here: https://github.com/beikov/surefire-test The problem is, that a simple parameterized JUnit test hangs when running in parallel mode on Linux. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193571#comment-16193571
]
Christian Beikov commented on SUREFIRE-1264:
Here it is: SUREFIRE-1430
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: failure-2.21-snapshot-SUREFIRE-1264.zip, pom.xml
>
> Time Spent: 144h
> Remaining Estimate: 24h
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec -
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's
> even more frequent/easy to reproduce.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193503#comment-16193503
]
Tibor Digana commented on SUREFIRE-1264:
[~christian.beikov]
I have reproduced the issue with minimum test on real box.
Can you please report a Jira issue related to platform Linux/Ubuntu with
external link pointing to github?
Current issue is about different root cause.
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: failure-2.21-snapshot-SUREFIRE-1264.zip, pom.xml
>
> Time Spent: 144h
> Remaining Estimate: 24h
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec -
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's
> even more frequent/easy to reproduce.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193415#comment-16193415
]
Christian Beikov commented on SUREFIRE-1264:
Here is a minimal test: https://github.com/beikov/surefire-test
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: failure-2.21-snapshot-SUREFIRE-1264.zip, pom.xml
>
> Time Spent: 144h
> Remaining Estimate: 24h
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec -
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's
> even more frequent/easy to reproduce.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193407#comment-16193407
]
Tibor Digana commented on SUREFIRE-1264:
[~cbeikov]
[~christian.beikov]
I am able to reproduce this issue on real box, Ubuntu 17.
I have investigated this issue a little bit.
It really looks like Surefire issue, but I cannot confirm unless isolated test
reproduces the issue with minimum dependencies. The fact is that there is JUnit
suite {{CalciteSuite.java}} has {{QuidemTest.java}} which is {{@Parameterized}}
JUnit test and the filter is specified
{{org/apache/calcite/test/CalciteSuite.java}}.
It really does not matter how many Threads you allocate.
Would you isolate it in a separate project in your account on GitHub? I want to
know if the single threaded Jdbc is the issue or dependencies. Let's avoid them.
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: failure-2.21-snapshot-SUREFIRE-1264.zip, pom.xml
>
> Time Spent: 144h
> Remaining Estimate: 24h
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec -
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's
> even more frequent/easy to reproduce.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193052#comment-16193052
]
Tibor Digana commented on SUREFIRE-1264:
[~cbeikov]
[~christian.beikov]
I guess you are using this configuration:
{quote}
1
true
both
once
{quote}
Try to change it to this:
{quote}
2
4
false
classesAndMethods
once
{quote}
I changed 4 parameters. Two classes run in parallel and 4 methods.
Let me know when Travis CI has finished.
I need to know if I should investigate parallel computer issue.
Thx.
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: failure-2.21-snapshot-SUREFIRE-1264.zip, pom.xml
>
> Time Spent: 144h
> Remaining Estimate: 24h
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec -
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's
> even more frequent/easy to reproduce.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJLINK-4) NPE on execution
[
https://issues.apache.org/jira/browse/MJLINK-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193009#comment-16193009
]
Jochen Mader commented on MJLINK-4:
---
[~j.boesl] I am on Mac OS 10.11.6.
> NPE on execution
> -
>
> Key: MJLINK-4
> URL: https://issues.apache.org/jira/browse/MJLINK-4
> Project: Maven JLink Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1
> Environment: Ubuntu 16.04.3 LTS
> Linux 4.4.0-93-generic
>Reporter: Johannes Boesl
>
> When I try to run my maven build I get the following exception:
> {quote}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project jloadr-jre: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project jloadr-jre: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:200)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:196)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at
> org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:52)
> at
> org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:48)
> at
> org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths(LocationManager.java:109)
> at
> org.apache.maven.plugins.jlink.JLinkMojo.preparePaths(JLinkMojo.java:347)
> at org.apache.maven.plugins.jlink.JLinkMojo.execute(JLinkMojo.java:264)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 12 more{quote}
> The cause seems to be that the following code in line 337 in JLinkMojo
> returns a collection with only 'null' entries:
> {{Collection dependencyArtifacts = getCompileClasspathElements(
> getProject() );}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJLINK-4) NPE on execution
[
https://issues.apache.org/jira/browse/MJLINK-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192933#comment-16192933
]
Johannes Boesl commented on MJLINK-4:
-
[~codepitbull] what os did you use? I'm using Ubuntu. Maybe it doesn't occur on
windows.
> NPE on execution
> -
>
> Key: MJLINK-4
> URL: https://issues.apache.org/jira/browse/MJLINK-4
> Project: Maven JLink Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1
> Environment: Ubuntu 16.04.3 LTS
> Linux 4.4.0-93-generic
>Reporter: Johannes Boesl
>
> When I try to run my maven build I get the following exception:
> {quote}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project jloadr-jre: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project jloadr-jre: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:200)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:196)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at
> org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:52)
> at
> org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:48)
> at
> org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths(LocationManager.java:109)
> at
> org.apache.maven.plugins.jlink.JLinkMojo.preparePaths(JLinkMojo.java:347)
> at org.apache.maven.plugins.jlink.JLinkMojo.execute(JLinkMojo.java:264)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 12 more{quote}
> The cause seems to be that the following code in line 337 in JLinkMojo
> returns a collection with only 'null' entries:
> {{Collection dependencyArtifacts = getCompileClasspathElements(
> getProject() );}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MTOOLCHAINS-21) plugin wiki never migrated from Codehaus
Ilya Basin created MTOOLCHAINS-21: - Summary: plugin wiki never migrated from Codehaus Key: MTOOLCHAINS-21 URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-21 Project: Maven Toolchains Plugin Issue Type: Bug Affects Versions: 1.1 Reporter: Ilya Basin Priority: Minor There's a dead link "[plugin's wiki page|http://docs.codehaus.org/display/MAVENUSER/Toolchains+Plugin]; on the [plugin's About page|http://maven.apache.org/plugins/maven-toolchains-plugin/index.html]. Looks like "MAVENUSER" was never migrated to cwiki.apache.org and any useful information about this plugin is lost. I desperately tried to find an archived copy on web.archive.org, but it's not there. If you have a copy, please publish it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MSHADE-258) RemappingClassAdapter is deprecated and throws an exception with ASM 6.0 beta
[
https://issues.apache.org/jira/browse/MSHADE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192790#comment-16192790
]
John Poth commented on MSHADE-258:
--
Hi [~rfscholte], [~ijuma],
What is it intentional to exclude the module-info.class from the original
artifact? Would it be possible to add an option to keep it?
Thanks!
> RemappingClassAdapter is deprecated and throws an exception with ASM 6.0 beta
> -
>
> Key: MSHADE-258
> URL: https://issues.apache.org/jira/browse/MSHADE-258
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ismael Juma
>Assignee: Robert Scholte
> Fix For: 3.1.0
>
>
> While trying to use the maven shade plugin with ASM 6.0 beta (for Java 9
> support) in the easymock project, I ran into the following exception:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on project
> easymock: Error creating shaded jar: Error in ASM processing class
> module-info.class: RemappingClassAdapter is deprecated, use ClassRemapper
> instead -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on
> project easymock: Error creating shaded jar: Error in ASM processing class
> module-info.class
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
> shaded jar: Error in ASM processing class module-info.class
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:546)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error in ASM
> processing class module-info.class
> at
> org.apache.maven.plugins.shade.DefaultShader.addRemappedClass(DefaultShader.java:453)
> at
> org.apache.maven.plugins.shade.DefaultShader.shadeSingleJar(DefaultShader.java:220)
> at
> org.apache.maven.plugins.shade.DefaultShader.shadeJars(DefaultShader.java:181)
> at
> org.apache.maven.plugins.shade.DefaultShader.shade(DefaultShader.java:104)
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:442)
> ... 22 more
> Caused by: java.lang.RuntimeException: RemappingClassAdapter is deprecated,
> use ClassRemapper instead
> at org.objectweb.asm.commons.RemappingClassAdapter.visitModule(Unknown
> Source)
> at org.objectweb.asm.ClassReader.a(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at
> org.apache.maven.plugins.shade.DefaultShader.addRemappedClass(DefaultShader.java:449)
> {code}
> Link to
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192759#comment-16192759
]
Tibor Digana commented on SUREFIRE-1264:
[~cbeikov]
[~christian.beikov]
Maybe we have talked about it but I would ask again.
Do you have a Thread Dump when Surefire 2.18 hanged in project
{{calcite-core}}?
Can you attach it?
Please use version 2.18 and not 2.18.1.
The old version definitely did not have new threading mechanism when Maven sent
tests to run to Surefire process via native process pipes.
It looks to me like the test class name was swallowed somewhere.
Are you open for building some Surefire branch by yourselves and perform some
experiments on your side?
Perhaps it would be nice dumping this cross-process communication when
debugging Maven build like this {{mvn -X test}} or {{mvn --debug test}}.
Thx.
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: failure-2.21-snapshot-SUREFIRE-1264.zip, pom.xml
>
> Time Spent: 144h
> Remaining Estimate: 24h
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec -
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's
> even more frequent/easy to reproduce.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192678#comment-16192678
]
Dan Berindei commented on SUREFIRE-1426:
{quote}
The system property maven.test.failure.ignore is not about masking your user
error nor system error. This is about ignoring events coming from JUnit
reflecting exception like Assumption|AssertionError or ordinal exception caught
by JUnit thrown by you test code.
{quote}
Then why does the build fail with {{-Dmaven.test.failure.ignore=false}} and
pass with {{-Dmaven.test.failure.ignore=true}}?
{quote}
I am no more willing to mask OutOfMemoryError and not to mask wrong
configuration because otherwise running tests would not makes sense!
{quote}
And yet Surefire *does* mask an OutOfMemoryError in the fork, if it happens in
the Surefire code and not in the user code.
{quote}
Then why you executed mvn test if you do not expect to run tests?
{quote}
That's exactly what I want, to run tests. But if I made a mistake and Surefire
cannot run the tests, I want to know so I can fix that mistake.
{quote}
And why you use maven.test.failure.ignore which everybody knows that it is
highly unrecommended in good s/w development
{quote}
Why exactly is {{-Dmaven.test.failure.ignore}} so highly unrecommended? Could
it be because it ignores all user and system errors, not just test failures?
Jenkins can read test results from the XMLs and mark the build as unstable or
failed, so {{-Dmaven.test.failure.ignore=false}} would work perfectly well in
this scenario *if* it ignored only test failures and not all the errors that
happen in the fork process.
{quote}
and why you simply did not skip tests -DskipTests if you do not like writing
and maintaining tests and you do not like high quality of s/w?
{quote}
What did I say to make you draw that conclusion? The fact that in a build with
20k+ tests I want more information than "no test failed" vs "at least one test
failed"?
> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> ---
>
> Key: SUREFIRE-1426
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1426
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Reporter: Dan Berindei
>Assignee: Tibor Digana
> Attachments: surefire-1426-test.tar.gz
>
>
> We have a reactor with many modules, and also a few random test failures. We
> want to run the tests of all the modules even if a test failed in the core
> module, so we use {{mvn -Dmaven.test.failure.ignore=true}}. {{mvn
> --fail-at-end}} only builds the modules that do not depend on the module with
> a failed test.
> The problem is that fork crashes like this one are written to the surefire
> reports, so Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an
> error in the forked process
> Unable to load category: stress
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:665)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at
[jira] [Comment Edited] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192612#comment-16192612
]
Tibor Digana edited comment on SUREFIRE-1426 at 10/5/17 8:48 AM:
-
If this log did not happen in {{target/surefire-reports}}, you would not know
it and you would blindly think everything was okay but it was not. Then stop
using {{-Dmaven.test.failure.ignore=true}} and do not use {{Freestyle in
Jenkins}} because Jenkins job implicitly sets {{maven.test.failure.ignore}} to
{{true}}. Pls set it to {{false}}. Again it is highly unrecommended to use such
property at all!
was (Author: tibor17):
If this log did not happen in {{target/surefire-reports}}, you would not know
it and you would blindly think everything was okay but it was not. Then stop
using {{-Dmaven.test.failure.ignore=true}} and do not use {{Freestyle in
Jenkins}} because this style implicitly sets {{maven.test.failure.ignore}} to
{{true}}. Pls set it to {{false}}. Again it is highly unrecommended to use such
property at all!
> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> ---
>
> Key: SUREFIRE-1426
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1426
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Reporter: Dan Berindei
>Assignee: Tibor Digana
> Attachments: surefire-1426-test.tar.gz
>
>
> We have a reactor with many modules, and also a few random test failures. We
> want to run the tests of all the modules even if a test failed in the core
> module, so we use {{mvn -Dmaven.test.failure.ignore=true}}. {{mvn
> --fail-at-end}} only builds the modules that do not depend on the module with
> a failed test.
> The problem is that fork crashes like this one are written to the surefire
> reports, so Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an
> error in the forked process
> Unable to load category: stress
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:665)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
--
This message was sent by Atlassian
[jira] [Created] (MPDF-83) Support JavaDoc report
Sébastien GARELLE created MPDF-83: - Summary: Support JavaDoc report Key: MPDF-83 URL: https://issues.apache.org/jira/browse/MPDF-83 Project: Maven PDF Plugin Issue Type: New Feature Affects Versions: 1.3 Reporter: Sébastien GARELLE Once [MPDF-48] fix will be released, reports based on 'internal' reporting plugins will be available in generated PDF documents. However 'external' reporting plugins, like JavaDoc have never been supported. Even if it raises technical challenges, and valid doubts on the readability of such reports in a PDF document, they are in some cases required (ex: regulatory requirement) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192616#comment-16192616
]
Tibor Digana edited comment on SUREFIRE-1426 at 10/5/17 8:46 AM:
-
When I had problems with Freestyle Jenkins I used
{{-Dmaven.test.failure.ignore=false}} (see how I set it explicitly to
{{false}}). Later I stopped using {{Freestyle}} and used Pipelines instead and
deprecated Freestyle jobs.
No more use Freestyle in Jenkins CI.
I switched to Multibranch Pipelines with Groovy Jenkinsfile script.
was (Author: tibor17):
When I had problems with Jenkins I used {{-Dmaven.test.failure.ignore=false}}
(see how I set it explicitly to {{false}}) and I stopped using {{Freestyle}}.
No more use Freestyle in Jenkins CI.
I switched to Multibranch Pipelines with Groovy Jenkinsfile script.
> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> ---
>
> Key: SUREFIRE-1426
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1426
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Reporter: Dan Berindei
>Assignee: Tibor Digana
> Attachments: surefire-1426-test.tar.gz
>
>
> We have a reactor with many modules, and also a few random test failures. We
> want to run the tests of all the modules even if a test failed in the core
> module, so we use {{mvn -Dmaven.test.failure.ignore=true}}. {{mvn
> --fail-at-end}} only builds the modules that do not depend on the module with
> a failed test.
> The problem is that fork crashes like this one are written to the surefire
> reports, so Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an
> error in the forked process
> Unable to load category: stress
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:665)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192616#comment-16192616
]
Tibor Digana commented on SUREFIRE-1426:
When I had problems with Jenkins I used {{-Dmaven.test.failure.ignore=false}}
(see how I set it explicitly to {{false}}) and I stopped using {{Freestyle}}.
No more use Freestyle in Jenkins CI.
I switched to Multibranch Pipelines with Groovy Jenkinsfile script.
> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> ---
>
> Key: SUREFIRE-1426
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1426
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Reporter: Dan Berindei
>Assignee: Tibor Digana
> Attachments: surefire-1426-test.tar.gz
>
>
> We have a reactor with many modules, and also a few random test failures. We
> want to run the tests of all the modules even if a test failed in the core
> module, so we use {{mvn -Dmaven.test.failure.ignore=true}}. {{mvn
> --fail-at-end}} only builds the modules that do not depend on the module with
> a failed test.
> The problem is that fork crashes like this one are written to the surefire
> reports, so Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an
> error in the forked process
> Unable to load category: stress
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:665)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192612#comment-16192612
]
Tibor Digana edited comment on SUREFIRE-1426 at 10/5/17 8:40 AM:
-
If this log did not happen in {{target/surefire-reports}}, you would not know
it and you would blindly think everything was okay but it was not. Then stop
using {{-Dmaven.test.failure.ignore=true}} and do not use {{Freestyle in
Jenkins}} because this style implicitly sets {{maven.test.failure.ignore}} to
{{true}}. Pls set it to {{false}}. Again it is highly unrecommended to use such
property at all!
was (Author: tibor17):
If this log did not happen in {{target/surefire-reports}}, you would not know
it and you would blindly think everything was okay but it was not. Then stop
using {{-Dmaven.test.failure.ignore=true}} and do not use {{Freestyle in
Jenkins}} because this style implicitly sets {{maven.test.failure.ignore}} to
{{true}. Pls set it to {{false}}. Again it is highly ubrecommended to use such
property at all!
> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> ---
>
> Key: SUREFIRE-1426
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1426
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Reporter: Dan Berindei
>Assignee: Tibor Digana
> Attachments: surefire-1426-test.tar.gz
>
>
> We have a reactor with many modules, and also a few random test failures. We
> want to run the tests of all the modules even if a test failed in the core
> module, so we use {{mvn -Dmaven.test.failure.ignore=true}}. {{mvn
> --fail-at-end}} only builds the modules that do not depend on the module with
> a failed test.
> The problem is that fork crashes like this one are written to the surefire
> reports, so Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an
> error in the forked process
> Unable to load category: stress
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:665)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
--
This message was sent by Atlassian
[jira] [Commented] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192612#comment-16192612
]
Tibor Digana commented on SUREFIRE-1426:
If this log did not happen in {{target/surefire-reports}}, you would not know
it and you would blindly think everything was okay but it was not. Then stop
using {{-Dmaven.test.failure.ignore=true}} and do not use {{Freestyle in
Jenkins}} because this style implicitly sets {{maven.test.failure.ignore}} to
{{true}. Pls set it to {{false}}. Again it is highly ubrecommended to use such
property at all!
> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> ---
>
> Key: SUREFIRE-1426
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1426
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Reporter: Dan Berindei
>Assignee: Tibor Digana
> Attachments: surefire-1426-test.tar.gz
>
>
> We have a reactor with many modules, and also a few random test failures. We
> want to run the tests of all the modules even if a test failed in the core
> module, so we use {{mvn -Dmaven.test.failure.ignore=true}}. {{mvn
> --fail-at-end}} only builds the modules that do not depend on the module with
> a failed test.
> The problem is that fork crashes like this one are written to the surefire
> reports, so Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an
> error in the forked process
> Unable to load category: stress
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:665)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192606#comment-16192606
]
Tibor Digana commented on SUREFIRE-1426:
[~dan.berindei]
Again yesterday your problem was the USER ERROR {{Unable to load category:
bogusGroup}} because you did not read documentation properly and did not pass
Java class to JUnit group.
Today you are coming with SYSTEM ERROR {{OOM}}.
The system property {{maven.test.failure.ignore}} is not about masking your
user error nor system error. This is about ignoring events coming from JUnit
reflecting exception like {{Assumption|AssertionError}} or ordinal exception
caught by JUnit thrown by you test code.
I am no more willing to mask {{OutOfMemoryError}} and not to mask wrong
configuration because otherwise running tests would not makes sense! Then why
you executed {{mvn test}} if you do not expect to run tests? And why you use
{{maven.test.failure.ignore}} which everybody knows that it is highly
unrecommended in good s/w development and why you simply did not skip tests
{{-DskipTests}} if you do not like writing and maintaining tests and you do not
like high quality of s/w?
> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> ---
>
> Key: SUREFIRE-1426
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1426
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Reporter: Dan Berindei
>Assignee: Tibor Digana
> Attachments: surefire-1426-test.tar.gz
>
>
> We have a reactor with many modules, and also a few random test failures. We
> want to run the tests of all the modules even if a test failed in the core
> module, so we use {{mvn -Dmaven.test.failure.ignore=true}}. {{mvn
> --fail-at-end}} only builds the modules that do not depend on the module with
> a failed test.
> The problem is that fork crashes like this one are written to the surefire
> reports, so Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an
> error in the forked process
> Unable to load category: stress
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:665)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
>
[jira] [Commented] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192582#comment-16192582
]
Dan Berindei commented on SUREFIRE-1426:
[~tibor17] this bug is not about *why* the fork fails, but about how that
failure is handled.
To give you another example, one of our build machines ran out of RAM and the
Linux OOM killer killed the fork process. Surefire ignored that failure (with
{{-Dmaven.test.failure.ignore=true}}), and the only sign of a problem in
Jenkins was a few thousand missing tests. Of course we should make sure the
machine doesn't run out of RAM, but we can't do that if we don't know there was
a problem.
{noformat}
Oct 4 12:53:23 infinispan-ci-slave-2 kernel: Out of memory: Kill process 27307
(java) score 758 or sacrifice child
{noformat}
{noformat}
org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM
terminated without properly saying goodbye. VM crash or System.exit called?
Command was /bin/sh -c cd
/home/infinispan/workspace/Infinispan_PR-5492-DVBKEZA6P52ZLMXFPQEPNR2W2HTQK3RCXEOZVUR7NNW4WLFIF3KQ/query
&& /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.144-0.b01.el7_4.x86_64/jre/bin/java
-javaagent:/home/infinispan/workspace/Infinispan_PR-5492-DVBKEZA6P52ZLMXFPQEPNR2W2HTQK3RCXEOZVUR7NNW4WLFIF3KQ/query/target/agents/byteman.jar=port:9091,boot:/home/infinispan/workspace/Infinispan_PR-5492-DVBKEZA6P52ZLMXFPQEPNR2W2HTQK3RCXEOZVUR7NNW4WLFIF3KQ/query/target/agents/byteman.jar
-Xmx2G -jar
/home/infinispan/workspace/Infinispan_PR-5492-DVBKEZA6P52ZLMXFPQEPNR2W2HTQK3RCXEOZVUR7NNW4WLFIF3KQ/query/target/surefire/surefirebooter2044542354484229757.jar
/home/infinispan/workspace/Infinispan_PR-5492-DVBKEZA6P52ZLMXFPQEPNR2W2HTQK3RCXEOZVUR7NNW4WLFIF3KQ/query/target/surefire
2017-10-04T12-38-56_198-jvmRun1 surefire1069399596138004989tmp
surefire_95078456212865687512tmp
Error occurred in starting fork, check output in log
Process Exit Code: 137
Crashed tests:
org.infinispan.query.affinity.AffinityTest
org.infinispan.query.affinity.ShardDistributionTest
org.infinispan.query.blackbox.ClusteredCacheWithAffinityIndexManagerTest
org.infinispan.query.blackbox.ClusteredCacheWithAffinityIndexManagerTxTest
org.infinispan.query.distributed.AffinityIndexManagerMassIndexTest
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:679)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
[jira] [Commented] (MSHARED-624) Upgrade of maven-shared-utils from 0.8 to 3.2.0.
[ https://issues.apache.org/jira/browse/MSHARED-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192521#comment-16192521 ] Hudson commented on MSHARED-624: UNSTABLE: Integrated in Jenkins build maven-shared #3760 (See [https://builds.apache.org/job/maven-shared/3760/]) [MSHARED-624] use released shared-utils 3.2.0 (hboutemy: [http://svn.apache.org/viewvc/?view=rev=1811158]) * (edit) maven-verifier/pom.xml > Upgrade of maven-shared-utils from 0.8 to 3.2.0. > > > Key: MSHARED-624 > URL: https://issues.apache.org/jira/browse/MSHARED-624 > Project: Maven Shared Components > Issue Type: Task > Components: maven-verifier >Reporter: Christian Schulte >Priority: Trivial > Fix For: maven-verifier-1.7 > > > to benefit from MSHARED-617 MSHARED-618 MSHARED-619 MSHARED-620 MSHARED-621 > MSHARED-622 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MSHARED-625) Refactored to use 'maven-shared-utils' instead of 'plexus-utils'.
[ https://issues.apache.org/jira/browse/MSHARED-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192520#comment-16192520 ] Hudson commented on MSHARED-625: UNSTABLE: Integrated in Jenkins build maven-shared #3760 (See [https://builds.apache.org/job/maven-shared/3760/]) [MSHARED-625] use released shared-utils 3.2.0 (hboutemy: [http://svn.apache.org/viewvc/?view=rev=1811159]) * (edit) maven-invoker/pom.xml > Refactored to use 'maven-shared-utils' instead of 'plexus-utils'. > -- > > Key: MSHARED-625 > URL: https://issues.apache.org/jira/browse/MSHARED-625 > Project: Maven Shared Components > Issue Type: Task > Components: maven-invoker >Reporter: Christian Schulte >Priority: Trivial > Fix For: maven-invoker-3.0.1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
