[jira] [Commented] (SUREFIRE-1197) Surefire 2.19 breaks tests under Windows due to fork problem

2015-12-04 Thread Hudson (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15042436#comment-15042436
 ] 

Hudson commented on SUREFIRE-1197:
--

SUCCESS: Integrated in maven-surefire #1515 (See 
[https://builds.apache.org/job/maven-surefire/1515/])
[SUREFIRE-1197] Surefire 2.19 breaks tests under Windows due to fork (tibor17: 
rev c733075bc90bcd6e07cdc60c24fa5c833e14cf6e)
* 
surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java
* 
surefire-providers/surefire-junit4/src/main/java/org/apache/maven/surefire/junit4/JUnit4Provider.java
* 
surefire-providers/surefire-testng/src/main/java/org/apache/maven/surefire/testng/TestNGProvider.java
* 
surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java


> Surefire 2.19 breaks tests under Windows due to fork problem
> 
>
> Key: SUREFIRE-1197
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1197
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.19
> Environment: Windows 7
>Reporter: Thorsten Meinl
>Assignee: Tibor Digana
> Fix For: 2.19.1
>
>
> After switching from Surefire 2.18.1 to 2.19 our tests under Windows have 
> stopped working (Linux and Mac are still running fine). The only error 
> message is
> Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) on 
> project server.ejb: Error occurred in starting fork, check output in log -> 
> [Help 1]
> (Full stacktrace below).
> Is checked the log and even enabled full debug messages but there is not 
> indication whatsoever what the problem can be. Given that everything worked 
> perfectly fine until we switched to 2.19 this seems to be a bug in this 
> version. I'm happy to provide further details if you tell me what you need 
> and how I can acquire it.
> ===
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) 
> on project server.ejb: Error occurred in starting fork, check output in log
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
>   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:120)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   at java.lang.reflect.Method.invoke(Method.java:507)
>   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.MojoFailureException: Error occurred in 
> starting fork, check output in log
>   at 
> org.apache.maven.plugin.surefire.SurefirePlugin.assertNoException(SurefirePlugin.java:326)
>   at 
> org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:316)
>   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:880)
>   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:739)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>   ... 19 more
> Caused by: org.apache.maven.sur

[jira] [Closed] (SUREFIRE-1203) Surefire hangs after Test Execution

2015-12-04 Thread Tibor Digana (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana closed SUREFIRE-1203.
--
Resolution: Duplicate

Seems to be duplicate of SUREFIRE-1193.

> Surefire hangs after Test Execution 
> 
>
> Key: SUREFIRE-1203
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1203
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19
> Environment: Jenkins 1.634
> Maven 3.0.4
> Oracle JDK1.7.0_15
> Maven goal: install
> Maven OPTS: -Xms512m -Xmx4096m -XX:MaxPermSize=2048m 
> -XX:ReservedCodeCacheSize=256m
>Reporter: Fabian Ehls
>Assignee: Tibor Digana
> Fix For: 2.19.1
>
>
> Console Output:
> {noformat}
> [INFO] --- maven-surefire-plugin:2.19:test (default-test) @ ourProject ---
> ---
>  T E S T S
> ---
> Running path.of.our.test.Test
> Running path.of.our.other.test.Test
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.517 sec - 
> in path.of.our.test.Test
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.589 sec - 
> in path.of.our.other.test.Test
> Results :
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> After this line the process hangs endlessly.
> A threadDump from the build Server shows the following:
> {noformat}
> Thread 21340: (state = IN_NATIVE)
>  - java.io.FileInputStream.readBytes(byte[], int, int) @bci=0 (Interpreted 
> frame)
>  - java.io.FileInputStream.read(byte[], int, int) @bci=4, line=242 
> (Interpreted frame)
>  - java.io.BufferedInputStream.fill() @bci=175, line=235 (Interpreted frame)
>  - java.io.BufferedInputStream.read() @bci=12, line=254 (Interpreted frame)
>  - java.io.DataInputStream.readInt() @bci=4, line=387 (Interpreted frame)
>  - 
> org.apache.maven.surefire.booter.MasterProcessCommand.decode(java.io.DataInputStream)
>  @bci=1, line=117 (Interpreted frame)
>  - 
> org.apache.maven.surefire.booter.MasterProcessReader.read(java.io.DataInputStream)
>  @bci=1, line=421 (Interpreted frame)
>  - 
> org.apache.maven.surefire.booter.MasterProcessReader.access$800(org.apache.maven.surefire.booter.MasterProcessReader,
>  java.io.DataInputStream) @bci=2, line=59 (Interpreted frame)
>  - org.apache.maven.surefire.booter.MasterProcessReader$CommandRunnable.run() 
> @bci=44, line=463 (Interpreted frame)
>  - java.lang.Thread.run() @bci=11, line=722 (Interpreted frame)
> {noformat}
> For me this looks like surefire is waiting for a file to read from..?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SUREFIRE-1203) Surefire hangs after Test Execution

2015-12-04 Thread Tibor Digana (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana updated SUREFIRE-1203:
---
Fix Version/s: 2.19.1

> Surefire hangs after Test Execution 
> 
>
> Key: SUREFIRE-1203
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1203
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19
> Environment: Jenkins 1.634
> Maven 3.0.4
> Oracle JDK1.7.0_15
> Maven goal: install
> Maven OPTS: -Xms512m -Xmx4096m -XX:MaxPermSize=2048m 
> -XX:ReservedCodeCacheSize=256m
>Reporter: Fabian Ehls
>Assignee: Tibor Digana
> Fix For: 2.19.1
>
>
> Console Output:
> {noformat}
> [INFO] --- maven-surefire-plugin:2.19:test (default-test) @ ourProject ---
> ---
>  T E S T S
> ---
> Running path.of.our.test.Test
> Running path.of.our.other.test.Test
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.517 sec - 
> in path.of.our.test.Test
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.589 sec - 
> in path.of.our.other.test.Test
> Results :
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> After this line the process hangs endlessly.
> A threadDump from the build Server shows the following:
> {noformat}
> Thread 21340: (state = IN_NATIVE)
>  - java.io.FileInputStream.readBytes(byte[], int, int) @bci=0 (Interpreted 
> frame)
>  - java.io.FileInputStream.read(byte[], int, int) @bci=4, line=242 
> (Interpreted frame)
>  - java.io.BufferedInputStream.fill() @bci=175, line=235 (Interpreted frame)
>  - java.io.BufferedInputStream.read() @bci=12, line=254 (Interpreted frame)
>  - java.io.DataInputStream.readInt() @bci=4, line=387 (Interpreted frame)
>  - 
> org.apache.maven.surefire.booter.MasterProcessCommand.decode(java.io.DataInputStream)
>  @bci=1, line=117 (Interpreted frame)
>  - 
> org.apache.maven.surefire.booter.MasterProcessReader.read(java.io.DataInputStream)
>  @bci=1, line=421 (Interpreted frame)
>  - 
> org.apache.maven.surefire.booter.MasterProcessReader.access$800(org.apache.maven.surefire.booter.MasterProcessReader,
>  java.io.DataInputStream) @bci=2, line=59 (Interpreted frame)
>  - org.apache.maven.surefire.booter.MasterProcessReader$CommandRunnable.run() 
> @bci=44, line=463 (Interpreted frame)
>  - java.lang.Thread.run() @bci=11, line=722 (Interpreted frame)
> {noformat}
> For me this looks like surefire is waiting for a file to read from..?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SUREFIRE-1197) Surefire 2.19 breaks tests under Windows due to fork problem

2015-12-04 Thread Tibor Digana (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana closed SUREFIRE-1197.
--
Resolution: Fixed

commit c733075bc90bcd6e07cdc60c24fa5c833e14cf6e

> Surefire 2.19 breaks tests under Windows due to fork problem
> 
>
> Key: SUREFIRE-1197
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1197
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.19
> Environment: Windows 7
>Reporter: Thorsten Meinl
>Assignee: Tibor Digana
> Fix For: 2.19.1
>
>
> After switching from Surefire 2.18.1 to 2.19 our tests under Windows have 
> stopped working (Linux and Mac are still running fine). The only error 
> message is
> Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) on 
> project server.ejb: Error occurred in starting fork, check output in log -> 
> [Help 1]
> (Full stacktrace below).
> Is checked the log and even enabled full debug messages but there is not 
> indication whatsoever what the problem can be. Given that everything worked 
> perfectly fine until we switched to 2.19 this seems to be a bug in this 
> version. I'm happy to provide further details if you tell me what you need 
> and how I can acquire it.
> ===
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) 
> on project server.ejb: Error occurred in starting fork, check output in log
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
>   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:120)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   at java.lang.reflect.Method.invoke(Method.java:507)
>   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.MojoFailureException: Error occurred in 
> starting fork, check output in log
>   at 
> org.apache.maven.plugin.surefire.SurefirePlugin.assertNoException(SurefirePlugin.java:326)
>   at 
> org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:316)
>   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:880)
>   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:739)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>   ... 19 more
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: 
> Error occurred in starting fork, check output in log
>   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:559)
>   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:461)
>   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:229)
>   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:201)
>   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1014)
>

[jira] [Comment Edited] (MJAVADOC-437) javadoc:aggregate fails on initial build

2015-12-04 Thread Michael Osipov (JIRA) 

[ 
https://issues.apache.org/jira/browse/MJAVADOC-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15042298#comment-15042298
 ] 

Michael Osipov edited comment on MJAVADOC-437 at 12/4/15 9:58 PM:
--

I would take MJAVADOC-275 IT as a starting point. Adapt names and classes and 
make it fail without your patch first. When it fails consistently, apply your 
patch and see what happens. The Invoker Plugin will create a new local repo 
after each clean phase, you should be able to reproduce your issue. If you have 
trouble, just ping me.


was (Author: michael-o):
I would take MJAVADOC-275 as a starting point. Adapt names and classes and mail 
it fail without your patch first. When it fails consistently, apply your patch 
and see what happens. The Invoker Plugin will create a new local repo after a 
clean, you should be able to reproduce your issue. If you have trouble, just 
ping me.

> javadoc:aggregate fails on initial build
> 
>
> Key: MJAVADOC-437
> URL: https://issues.apache.org/jira/browse/MJAVADOC-437
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.10.3
>Reporter: Harald Wellmann
>Assignee: Michael Osipov
>
> h3. Scenario
> Take a SNAPSHOT version of a reactor project with at least two JAR modules.
> Assume that no artifacts of the given SNAPSHOT version have been built before 
> (this is usually the case just after running release:perform).
> h3. Actual Behaviour
> Now run {{mvn javadoc:aggregate}}. This build fails in the forked lifecycle. 
> maven-javadoc-plugin unnecessarily tries to resolve the JAR artifacts of the 
> current reactor (which are not avialable yet) and add them to the Javadoc 
> classpath.
> h3. Expected Behaviour
> Aggregated Javadoc should be generated without problems. It is sufficient to 
> take the sources of the current reactor and only put *external* dependencies 
> on the Javadoc classpath.
> This is a duplicate of an 8 year old bug MJAVADOC-116 with 51 votes which has 
> been closed without being fixed.
> A patch for this problem was submitted in MJAVADOC-362, but does not seem to 
> have received attention by committers. (I admit the problem description is 
> not very clear.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MJAVADOC-437) javadoc:aggregate fails on initial build

2015-12-04 Thread Michael Osipov (JIRA) 

[ 
https://issues.apache.org/jira/browse/MJAVADOC-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15042298#comment-15042298
 ] 

Michael Osipov commented on MJAVADOC-437:
-

I would take MJAVADOC-275 as a starting point. Adapt names and classes and mail 
it fail without your patch first. When it fails consistently, apply your patch 
and see what happens. The Invoker Plugin will create a new local repo after a 
clean, you should be able to reproduce your issue. If you have trouble, just 
ping me.

> javadoc:aggregate fails on initial build
> 
>
> Key: MJAVADOC-437
> URL: https://issues.apache.org/jira/browse/MJAVADOC-437
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.10.3
>Reporter: Harald Wellmann
>Assignee: Michael Osipov
>
> h3. Scenario
> Take a SNAPSHOT version of a reactor project with at least two JAR modules.
> Assume that no artifacts of the given SNAPSHOT version have been built before 
> (this is usually the case just after running release:perform).
> h3. Actual Behaviour
> Now run {{mvn javadoc:aggregate}}. This build fails in the forked lifecycle. 
> maven-javadoc-plugin unnecessarily tries to resolve the JAR artifacts of the 
> current reactor (which are not avialable yet) and add them to the Javadoc 
> classpath.
> h3. Expected Behaviour
> Aggregated Javadoc should be generated without problems. It is sufficient to 
> take the sources of the current reactor and only put *external* dependencies 
> on the Javadoc classpath.
> This is a duplicate of an 8 year old bug MJAVADOC-116 with 51 votes which has 
> been closed without being fixed.
> A patch for this problem was submitted in MJAVADOC-362, but does not seem to 
> have received attention by committers. (I admit the problem description is 
> not very clear.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5939) Problem doing release when sources are generate as well

2015-12-04 Thread Jason Mihalick (JIRA) 

[ 
https://issues.apache.org/jira/browse/MNG-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041712#comment-15041712
 ] 

Jason Mihalick commented on MNG-5939:
-

Again, thank you. Your question forced me to recheck my parent POMs, and, sure 
enough, I still had a left over configuration for the maven-source-plugin in 
one of my pluginManagement sections. Once I eliminated that and I released my 
child project, my release worked!  So now I have confirmed your workaround and 
we are left to wonder if someone will investigate the potential source for the 
problem which I provided below.

> Problem doing release when sources are generate as well
> ---
>
> Key: MNG-5939
> URL: https://issues.apache.org/jira/browse/MNG-5939
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.3.3, 3.3.9
> Environment: Ubuntu 12.04.5 LTS
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 
> 2014-02-14T18:37:52+01:00)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T17:41:47+01:00)
> Java version: 1.7.0_76, vendor: Oracle Corporation
>Reporter: chibbe
> Attachments: foo.bar.zip
>
>
> If I specified that sources should be generated with jar-no-fork goal 
> https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html .
> When doing a release with maven-release-plugin it will build the source again 
> when useReleaseProfile is true (use the release profile that adds sources and 
> javadocs to the released artifact 
> http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile).
> The outcome is that it will run with both jar and jar-no-fork and generate 
> and deploy 2 -sources.jar artifacts, with same version. That makes the 
> release build fails.
>  
> The same behavior could be reproduced when running both jar and jar-no-fork 
> goal between maven 3.2.1. and maven 3.3.9.
> 
> Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip
> With maven 3.3.9 it uploads it 2 times :
> Uploaded: 
> http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar
>  (722 B at 15.3 KB/sec)
> Uploading: 
> http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar
> 722/722 B



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MSHARED-428) maven-dependency-analyzer does not detect method references

2015-12-04 Thread Jonathan Haber (JIRA) 

[ 
https://issues.apache.org/jira/browse/MSHARED-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041657#comment-15041657
 ] 

Jonathan Haber commented on MSHARED-428:


Thanks! Do you know when 1.7 will be released?

> maven-dependency-analyzer does not detect method references
> ---
>
> Key: MSHARED-428
> URL: https://issues.apache.org/jira/browse/MSHARED-428
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.6
>Reporter: Jonathan Haber
>Assignee: Kristian Rosenvold
> Fix For: maven-dependency-analyzer-1.7
>
>
> maven-dependency-analyzer doesn't seem to pick up on method reference usages. 
> When using the maven-dependency-plugin, if the only usage of a dependency is 
> via a method reference, this causes erroneous unused dependency errors that 
> fail our build. 
> I updated the maven-dependency-analyzer tests to fail and pushed it to our 
> fork:
> https://github.com/HubSpot/maven-shared/commit/d5ffacb808fba01837c644f2045a79eab50fecbf
> Changing from a method reference to a lambda or anonymous class makes the 
> test pass again.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MSHARED-416) Odd number of quotes in command-line fails

2015-12-04 Thread Kristian Rosenvold (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MSHARED-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MSHARED-416:
---
Component/s: maven-shared-utils

> Odd number of quotes in command-line fails
> --
>
> Key: MSHARED-416
> URL: https://issues.apache.org/jira/browse/MSHARED-416
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-shared-utils
>Reporter: Eric Citaire
> Attachments: QuoteTest.java
>
>
> When using org.apache.maven.shared.utils.cli.Commandline, if the command 
> contains a single-quote, the execution fails with output :
> {{/bin/sh: 1: Syntax error: Unterminated quoted string}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MSHARED-297) Commandline class shell injection vulnerabilities

2015-12-04 Thread Kristian Rosenvold (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MSHARED-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MSHARED-297:
---
Component/s: maven-shared-utils

> Commandline class shell injection vulnerabilities
> -
>
> Key: MSHARED-297
> URL: https://issues.apache.org/jira/browse/MSHARED-297
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-shared-utils
>Reporter: Charles Duffy
> Attachments: use-no-shell-r2.patch
>
>
> The Commandline class can emit double-quoted strings without proper escaping, 
> allowing shell injection attacks.
> The BourneShell class should unconditionally single-quote emitted strings 
> (including the name of the command itself being quoted), with {{'"'"'}} used 
> for embedded single quotes, for maximum safety across shells implementing a 
> superset of POSIX quoting rules.
> An appropriate fix has been built and applied against PLXUTILS; that patch is 
> submitted here in the hope that it will be useful, though it is not expected 
> to apply to the maven-shared-utils codebase without modification.
> See PLXUTILS-161 for history/discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MSHARED-317) Analyzer reports unused dependencies between modules in multi-module project

2015-12-04 Thread Kristian Rosenvold (JIRA) 

[ 
https://issues.apache.org/jira/browse/MSHARED-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041622#comment-15041622
 ] 

Kristian Rosenvold commented on MSHARED-317:


The JDK8 fixes in r1717974 will solve this issue for jdk8 users. It should be 
possible to solve this for earlier versions if someone does the job.

> Analyzer reports unused dependencies between modules in multi-module project
> 
>
> Key: MSHARED-317
> URL: https://issues.apache.org/jira/browse/MSHARED-317
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.4
>Reporter: Krzysztof Krason
>
> I have  Multi module project:
> parent
>  - exception
>  - exception-user
> In "exception-user" I added dependency on "exception" and throw given 
> exception in one class.
> Depdencency analyzer reports that dependency on "exception" is unused.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MSHARED-428) maven-dependency-analyzer does not detect method references

2015-12-04 Thread Kristian Rosenvold (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MSHARED-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MSHARED-428:
---
Fix Version/s: maven-dependency-analyzer-1.7

> maven-dependency-analyzer does not detect method references
> ---
>
> Key: MSHARED-428
> URL: https://issues.apache.org/jira/browse/MSHARED-428
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.6
>Reporter: Jonathan Haber
>Assignee: Kristian Rosenvold
> Fix For: maven-dependency-analyzer-1.7
>
>
> maven-dependency-analyzer doesn't seem to pick up on method reference usages. 
> When using the maven-dependency-plugin, if the only usage of a dependency is 
> via a method reference, this causes erroneous unused dependency errors that 
> fail our build. 
> I updated the maven-dependency-analyzer tests to fail and pushed it to our 
> fork:
> https://github.com/HubSpot/maven-shared/commit/d5ffacb808fba01837c644f2045a79eab50fecbf
> Changing from a method reference to a lambda or anonymous class makes the 
> test pass again.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MSHARED-428) maven-dependency-analyzer does not detect method references

2015-12-04 Thread Kristian Rosenvold (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MSHARED-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MSHARED-428.
--
Resolution: Fixed
  Assignee: Kristian Rosenvold

Fixed in r1717974

> maven-dependency-analyzer does not detect method references
> ---
>
> Key: MSHARED-428
> URL: https://issues.apache.org/jira/browse/MSHARED-428
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.6
>Reporter: Jonathan Haber
>Assignee: Kristian Rosenvold
>
> maven-dependency-analyzer doesn't seem to pick up on method reference usages. 
> When using the maven-dependency-plugin, if the only usage of a dependency is 
> via a method reference, this causes erroneous unused dependency errors that 
> fail our build. 
> I updated the maven-dependency-analyzer tests to fail and pushed it to our 
> fork:
> https://github.com/HubSpot/maven-shared/commit/d5ffacb808fba01837c644f2045a79eab50fecbf
> Changing from a method reference to a lambda or anonymous class makes the 
> test pass again.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MJAVADOC-437) javadoc:aggregate fails on initial build

2015-12-04 Thread Harald Wellmann (JIRA) 

[ 
https://issues.apache.org/jira/browse/MJAVADOC-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041598#comment-15041598
 ] 

Harald Wellmann commented on MJAVADOC-437:
--

Ok, I'll give it a try. I'm not too familiar with the IT setup of Maven's own 
plugins... (I did run mvn install -Prun-its with my patch, so at least I'm 
confident it doesn't break anything.)

Can you recommend a good starting point, i.e. a particular test to copy and 
modify?

> javadoc:aggregate fails on initial build
> 
>
> Key: MJAVADOC-437
> URL: https://issues.apache.org/jira/browse/MJAVADOC-437
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.10.3
>Reporter: Harald Wellmann
>Assignee: Michael Osipov
>
> h3. Scenario
> Take a SNAPSHOT version of a reactor project with at least two JAR modules.
> Assume that no artifacts of the given SNAPSHOT version have been built before 
> (this is usually the case just after running release:perform).
> h3. Actual Behaviour
> Now run {{mvn javadoc:aggregate}}. This build fails in the forked lifecycle. 
> maven-javadoc-plugin unnecessarily tries to resolve the JAR artifacts of the 
> current reactor (which are not avialable yet) and add them to the Javadoc 
> classpath.
> h3. Expected Behaviour
> Aggregated Javadoc should be generated without problems. It is sufficient to 
> take the sources of the current reactor and only put *external* dependencies 
> on the Javadoc classpath.
> This is a duplicate of an 8 year old bug MJAVADOC-116 with 51 votes which has 
> been closed without being fixed.
> A patch for this problem was submitted in MJAVADOC-362, but does not seem to 
> have received attention by committers. (I admit the problem description is 
> not very clear.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SUREFIRE-1205) -Dtest option did not work with test methods in different classes

2015-12-04 Thread Artem Koshelev (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Artem Koshelev closed SUREFIRE-1205.

Resolution: Cannot Reproduce

i'm sorry, it's just something wrong with my tests

> -Dtest option did not work with test methods in different classes
> -
>
> Key: SUREFIRE-1205
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1205
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Reporter: Artem Koshelev
>
> I want to run a set of test methods from different classes, and according to 
> documentation, i run it with option 
> "-Dtest=my.test.class1#myMethod,my.test.class2#myOtherMethod". For every but 
> last class i've got a message in log, that it was running, but then got 
> 0/0/0/0 result. The last passed test method executes correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1202) Allow rerunFailingTestsCount, skipAfterFailureCount together

2015-12-04 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041462#comment-15041462
 ] 

ASF GitHub Bot commented on SUREFIRE-1202:
--

Github user Tibor17 commented on the pull request:

https://github.com/apache/maven-surefire/pull/108#issuecomment-161945817
  
@seanf 
>>Are you saying you did try to build an IT for this?
reuseForks=false would not work in 2.19 feature.
Initially skipAfterFailureCount was not count because it was boolean and 
therefore rerunFailingTestsCount did not make sense.
Now it may have sense.

>>What counts would you consider realistic?
Maybe 5 test classes or more with Thread.sleep() 3 seconds, forkCount=2, 
rerunFailingTestsCount = 3 and skipAfterFailureCount=2. There should be two 
tests. One should work with #failures < rerunFailingTestsCount (all 5 test 
classes passed with flaky tests), and second test in IT where #failures > 
rerunFailingTestsCount (totally maybe only 3 or 4 test classes run and two 
failed). Each class has one method.
The classes are ordered on alphabetical order and forked.
That's my idea but you can improve it of course and the system properties 
can be used in order to force tests to fail e.g.
```
 @Test test() {
  if (sys-prop) Assert.fail();
}
```
Let's see how long sleep() should be in the tests..

>>I'm still assuming failureCount is meant to count failed tests, not bad
runs. You didn't answer my question about that (and the docs don't say),
but I do think it is better to count tests, as long as it is documented.

If the rerun is enabled, the flaky tests (I mean those bad tests < 
rerunFailingTestsCount) should not be a subject to the feature with 
skipAfterFailureCount. I don't remember the code in detail. We need the IT to 
confirm both features may work together.

>>As I said, there should be no race condition if failureCount counts
(completely) failed tests, assuming the runs for each test are serialised.
Race condition is between forks. In extremely short test method race 
condition may happen and the failure count may grow over expected 
skipAfterFailureCount .



> Allow rerunFailingTestsCount, skipAfterFailureCount together
> 
>
> Key: SUREFIRE-1202
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1202
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin
>Affects Versions: 2.19
>Reporter: Sean Flanigan
>Assignee: Tibor Digana
>
> I couldn't find this limitation documented anywhere, but if I try to use the 
> options {{rerunFailingTestsCount}} and {{skipAfterFailureCount}} together, I 
> get this error message:
> {noformat}
> org.apache.maven.plugin.MojoFailureException: 
> Parameters ["rerunFailingTestsCount", "skipAfterFailureCount"] 
> should not be enabled together
> {noformat}
> I have a use case which requires both options: some integration tests are 
> flaky, so I want to use {{rerunFailingTestsCount}} to repeat them, but if all 
> tests are failing (eg due to a configuration problem or a really bad change), 
> I don't want to wait for the entire test suite to fail multiple times, so I 
> would like to abort if say 10 tests have failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5719) rename JavaToolChain to JavaToolchain for consistency and don't declare it as Plexus component

2015-12-04 Thread *$^¨%`£ 

[ 
https://issues.apache.org/jira/browse/MNG-5719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041404#comment-15041404
 ] 

Olivier Lamy (*$^¨%`£) commented on MNG-5719:
-

cause https://github.com/mojohaus/animal-sniffer/pull/6
now will be a pain to get the plugin working with older maven version

> rename JavaToolChain to JavaToolchain for consistency and don't declare it as 
> Plexus component
> --
>
> Key: MNG-5719
> URL: https://issues.apache.org/jira/browse/MNG-5719
> Project: Maven
>  Issue Type: Wish
>  Components: Toolchains
>Affects Versions: 3.2.3
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 3.2.5
>
>
> since these classes are not used directly, this should not cause any harm



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SUREFIRE-1205) -Dtest option did not work with test methods in different classes

2015-12-04 Thread Artem Koshelev (JIRA) 
Artem Koshelev created SUREFIRE-1205:


 Summary: -Dtest option did not work with test methods in different 
classes
 Key: SUREFIRE-1205
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1205
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Reporter: Artem Koshelev


I want to run a set of test methods from different classes, and according to 
documentation, i run it with option 
"-Dtest=my.test.class1#myMethod,my.test.class2#myOtherMethod". For every but 
last class i've got a message in log, that it was running, but then got 0/0/0/0 
result. The last passed test method executes correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SUREFIRE-1204) -Dtest= option is broken in 2.19

2015-12-04 Thread Artem Koshelev (JIRA) 
Artem Koshelev created SUREFIRE-1204:


 Summary: -Dtest= option is broken in 2.19
 Key: SUREFIRE-1204
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1204
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Reporter: Artem Koshelev


i tried to run specific method passing parameter 
"-Dtest=my.package.myClass#myMethod" but got "no tests were executed"

it works in previous version (2.14-2.18)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1202) Allow rerunFailingTestsCount, skipAfterFailureCount together

2015-12-04 Thread Tibor Digana (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041337#comment-15041337
 ] 

Tibor Digana commented on SUREFIRE-1202:


>>Are you saying you did try to build an IT for this?
reuseForks=false would not work in 2.19 feature.
Initially skipAfterFailureCount  was not count because it was boolean and 
therefore rerunFailingTestsCount did not make sense.
Now it may have sense.

>>What counts would you consider realistic?
Maybe 5 test classes or more with Thread.sleep() 3 seconds, forkCount=2, 
rerunFailingTestsCount = 3 and skipAfterFailureCount=2. There should be two 
tests. One should work with #failures < rerunFailingTestsCount (all 5 test 
classes passed with flaky tests), and second test in IT where #failures > 
rerunFailingTestsCount (totally maybe only 3 or 4 test classes run and two 
failed). Each class has one method.
The classes are ordered on alphabetical order and forked.
That's my idea but you can improve it of course and the system properties can 
be used in order to force tests to fail e.g.
{code}
 @Test test() {
  if (sys-prop) Assert.fail();
}
{code}
Let's see how long sleep() should be in the tests..

>>I'm still assuming failureCount is meant to count failed tests, not bad
runs. You didn't answer my question about that (and the docs don't say),
but I do think it is better to count tests, as long as it is documented.

If the rerun is enabled, the flaky tests (I mean those bad tests < 
rerunFailingTestsCount) should not be a subject to the feature with 
skipAfterFailureCount. I don't remember the code in detail. We need the IT to 
confirm both features may work together.

>>As I said, there should be no race condition if failureCount counts
(completely) failed tests, assuming the runs for each test are serialised.
Race condition is between forks. In extremely short test method race condition 
may happen and the failure count may grow over expected skipAfterFailureCount .

> Allow rerunFailingTestsCount, skipAfterFailureCount together
> 
>
> Key: SUREFIRE-1202
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1202
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin
>Affects Versions: 2.19
>Reporter: Sean Flanigan
>Assignee: Tibor Digana
>
> I couldn't find this limitation documented anywhere, but if I try to use the 
> options {{rerunFailingTestsCount}} and {{skipAfterFailureCount}} together, I 
> get this error message:
> {noformat}
> org.apache.maven.plugin.MojoFailureException: 
> Parameters ["rerunFailingTestsCount", "skipAfterFailureCount"] 
> should not be enabled together
> {noformat}
> I have a use case which requires both options: some integration tests are 
> flaky, so I want to use {{rerunFailingTestsCount}} to repeat them, but if all 
> tests are failing (eg due to a configuration problem or a really bad change), 
> I don't want to wait for the entire test suite to fail multiple times, so I 
> would like to abort if say 10 tests have failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5939) Problem doing release when sources are generate as well

2015-12-04 Thread chibbe (JIRA) 

[ 
https://issues.apache.org/jira/browse/MNG-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041327#comment-15041327
 ] 

chibbe commented on MNG-5939:
-

Its not hidden in  (in some parent pom)?
Im able to reproduce it with:

{code:xml}



org.apache.maven.plugins
maven-source-plugin
2.4


attach-sources

jar








org.apache.maven.plugins
maven-source-plugin
2.4



jar







{code}

And in effective pom I get:

{code:xml}
  
maven-source-plugin
2.4

  

  jar

  
  
attach-sources

  jar

  

  
{code}

> Problem doing release when sources are generate as well
> ---
>
> Key: MNG-5939
> URL: https://issues.apache.org/jira/browse/MNG-5939
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.3.3, 3.3.9
> Environment: Ubuntu 12.04.5 LTS
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 
> 2014-02-14T18:37:52+01:00)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T17:41:47+01:00)
> Java version: 1.7.0_76, vendor: Oracle Corporation
>Reporter: chibbe
> Attachments: foo.bar.zip
>
>
> If I specified that sources should be generated with jar-no-fork goal 
> https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html .
> When doing a release with maven-release-plugin it will build the source again 
> when useReleaseProfile is true (use the release profile that adds sources and 
> javadocs to the released artifact 
> http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile).
> The outcome is that it will run with both jar and jar-no-fork and generate 
> and deploy 2 -sources.jar artifacts, with same version. That makes the 
> release build fails.
>  
> The same behavior could be reproduced when running both jar and jar-no-fork 
> goal between maven 3.2.1. and maven 3.3.9.
> 
> Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip
> With maven 3.3.9 it uploads it 2 times :
> Uploaded: 
> http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar
>  (722 B at 15.3 KB/sec)
> Uploading: 
> http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar
> 722/722 B



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1202) Allow rerunFailingTestsCount, skipAfterFailureCount together

2015-12-04 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041286#comment-15041286
 ] 

ASF GitHub Bot commented on SUREFIRE-1202:
--

Github user seanf commented on the pull request:

https://github.com/apache/maven-surefire/pull/108#issuecomment-161909472
  
Hi Tibor,

I don't understand. Are you saying you did try to build an IT for this?
Could you share it, please? What counts would you consider realistic?

I won't have any time to look at the code for a few days, but running a
test more than once *in series* (not parallel) should not affect
concurrency, because the test hasn't failed until all runs for that test
have finished.

I'm still assuming failureCount is meant to count failed tests, not bad
runs. You didn't answer my question about that (and the docs don't say),
but I do think it is better to count tests, as long as it is documented.

As I said, there should be no race condition if failureCount counts
(completely) failed tests, assuming the runs for each test are serialised.

Sean.

On 3 December 2015 at 01:38, Tibor Digana  wrote:

> Try to build IT with your code with more realistic counts, but the
> fail-fast feature would not be coherent due to concurrency problem across
> forks.
>
> —
> Reply to this email directly or view it on GitHub
> 
> .
>



> Allow rerunFailingTestsCount, skipAfterFailureCount together
> 
>
> Key: SUREFIRE-1202
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1202
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin
>Affects Versions: 2.19
>Reporter: Sean Flanigan
>Assignee: Tibor Digana
>
> I couldn't find this limitation documented anywhere, but if I try to use the 
> options {{rerunFailingTestsCount}} and {{skipAfterFailureCount}} together, I 
> get this error message:
> {noformat}
> org.apache.maven.plugin.MojoFailureException: 
> Parameters ["rerunFailingTestsCount", "skipAfterFailureCount"] 
> should not be enabled together
> {noformat}
> I have a use case which requires both options: some integration tests are 
> flaky, so I want to use {{rerunFailingTestsCount}} to repeat them, but if all 
> tests are failing (eg due to a configuration problem or a really bad change), 
> I don't want to wait for the entire test suite to fail multiple times, so I 
> would like to abort if say 10 tests have failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)