[jira] [Commented] (SUREFIRE-2141) Surefire 3.0.0-M8 tests don't pass on Mac M1 (Surefire1295AttributeJvmCrashesToTestsIT)
[
https://issues.apache.org/jira/browse/SUREFIRE-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17676535#comment-17676535
]
Tibor Digana commented on SUREFIRE-2141:
Regarding the history, one of our contributors created a project, released Jar
atrifact which contains native libraries.
This artifact is not part of Surefire/Failsafe plugin.
It is used only in our ITs.
Naturally ARM is not supported because that time ARM was not much popular,
maybe only on the embedded systems.
So, if you want to have the support, try to find the guy according to the
history in GitHub. Otherwise, feel free to skip the tests for this CPU.
> Surefire 3.0.0-M8 tests don't pass on Mac M1
> (Surefire1295AttributeJvmCrashesToTestsIT)
> ---
>
> Key: SUREFIRE-2141
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2141
> Project: Maven Surefire
> Issue Type: New Feature
>Affects Versions: 3.0.0-M8
>Reporter: Enrico Olivelli
>Priority: Critical
>
>
> This test never passes on M1 Macs: Surefire1295AttributeJvmCrashesToTestsIT
> This is the error I can find in
> surefire-its/target/Surefire1295AttributeJvmCrashesToTestsIT_test_segfault_2/target/surefire-reports/junit44.environment.Test1CrashedTest.txt
> The problem is in the crashjvm library
> https://mvnrepository.com/artifact/uk.me.mjt/crashjvm/1.0
> The library seems dead
> {code:java}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.546 s <<<
> FAILURE! - in junit44.environment.Test1CrashedTest
> junit44.environment.Test1CrashedTest.testCrashJvm Time elapsed: 1.53 s <<<
> ERROR!
> java.lang.ExceptionInInitializerError
> at
> junit44.environment.Test1CrashedTest.testCrashJvm(Test1CrashedTest.java:34)
> 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.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> at
> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> at
> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> at
> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> at
> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> at
> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> at
> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> at
> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)
> Caused by: java.lang.RuntimeException: Unrecognised arch, aarch64
> at uk.me.mjt.FindLibrary.getArch(FindLibrary.java:142)
> at
> uk.me.mjt.FindLibrary.extractNativeLibAsTempFile(FindLibrary.java:108)
> at uk.me.mjt.FindLibrary.loadLibraryFromJarFile(FindLibrary.java:44)
> at
> uk.me.mjt.FindLibrary.loadLibraryExtractingFromJarIfNeeded(FindLibrary.java:25)
> at uk.me.mjt.CrashJvm.(CrashJvm.java:5)
> ... 25 more
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-1334) Issue a warning in case argLine is set in conjunction with forkCount=0
[
https://issues.apache.org/jira/browse/SUREFIRE-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961773#comment-15961773
]
Tibor Digana edited comment on SUREFIRE-1334 at 4/8/17 10:31 AM:
-
[~apache-bugzi...@sebastian-kirsch.org]
[~sebastiankirsch]
Pls provide a fix in pull request.
You can add sanity checks in {{AbstractSurefireMojo}} and see already existing
sanity checks.
was (Author: tibor17):
[~apache-bugzi...@sebastian-kirsch.org]
[~sebastiankirsch]
Pls provide a fi in pull request.
You can add sanity checks in {{AbstractSurefireMojo}} and see already existing
sanity checks.
> Issue a warning in case argLine is set in conjunction with forkCount=0
> --
>
> Key: SUREFIRE-1334
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1334
> Project: Maven Surefire
> Issue Type: Wish
> Components: Maven Surefire Plugin
>Affects Versions: 2.18.1
>Reporter: Sebastian Kirsch
>
> I just spend some considerable amount of time figuring out why JaCoCo
> wouldn't work for a Maven project. The reason is that the JaCoCo Maven plugin
> sets the {{argLine}} property with a {{javaagent}} which causes the coverage
> to be generated and reported - but with {{forkCount}} being set to {{0}}, the
> {{argLine}} parameter has no effect.
> Now hindsight is 20/20, but I think it would be helpful if surefire would
> simply report a warning in case the {{argLine}} property is set, but will not
> have an effect.
> I assume the same is true for the {{systemProperties}},
> {{systemPropertiesFile}}, {{systemPropertyVariables}}, and maybe others.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1334) Issue a warning in case argLine is set in conjunction with forkCount=0
[
https://issues.apache.org/jira/browse/SUREFIRE-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961773#comment-15961773
]
Tibor Digana commented on SUREFIRE-1334:
[~apache-bugzi...@sebastian-kirsch.org]
[~sebastiankirsch]
Pls provide a fi in pull request.
You can add sanity checks in {{AbstractSurefireMojo}} and see already existing
sanity checks.
> Issue a warning in case argLine is set in conjunction with forkCount=0
> --
>
> Key: SUREFIRE-1334
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1334
> Project: Maven Surefire
> Issue Type: Wish
> Components: Maven Surefire Plugin
>Affects Versions: 2.18.1
>Reporter: Sebastian Kirsch
>
> I just spend some considerable amount of time figuring out why JaCoCo
> wouldn't work for a Maven project. The reason is that the JaCoCo Maven plugin
> sets the {{argLine}} property with a {{javaagent}} which causes the coverage
> to be generated and reported - but with {{forkCount}} being set to {{0}}, the
> {{argLine}} parameter has no effect.
> Now hindsight is 20/20, but I think it would be helpful if surefire would
> simply report a warning in case the {{argLine}} property is set, but will not
> have an effect.
> I assume the same is true for the {{systemProperties}},
> {{systemPropertiesFile}}, {{systemPropertyVariables}}, and maybe others.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1325) Monitoring the testing memory consumption and printed with elapsed time
[ https://issues.apache.org/jira/browse/SUREFIRE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961785#comment-15961785 ] Tibor Digana commented on SUREFIRE-1325: [~Bingoko] Having the elapsed time would help me too, but the memory consumption should fixed after I introduce a new format of stream. The format transfers data from forked jvm to Maven process. If you want to you can patch the elapsed time and open pull request in GitHub. > Monitoring the testing memory consumption and printed with elapsed time > --- > > Key: SUREFIRE-1325 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1325 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin, process forking >Reporter: Bob Li > Labels: profiler > Original Estimate: 12h > Remaining Estimate: 12h > > As the user, the elapsed time for executing the test case is important, but I > think the memory consumption is also important. > I think the maven surefire could printed both of them for the user. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961788#comment-15961788
]
Tibor Digana commented on SUREFIRE-1314:
[~mishail]
Sorry but this is not our problem.
Ask the JUnit team. What version of JUnit you use?
Check it out with new provider {{surefire-junit47}}.
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961793#comment-15961793
]
Tibor Digana commented on SUREFIRE-1302:
[~xeagle]
I used version 2.20 and found out that forked jvm received corrupted data in
stdin (java.lang.System#in).
Some library uses stdin in your tests.
# Created on 2017-04-08T13:28:55.139
[SUREFIRE] std/in stream corrupted
java.io.IOException: Command NOOP unexpectedly read Void data with length 4.
at
org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
at
org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
at java.lang.Thread.run(Thread.java:745)
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: Backlog
>
> Attachments:
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1325) Monitoring the testing memory consumption and printed with elapsed time
[ https://issues.apache.org/jira/browse/SUREFIRE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961785#comment-15961785 ] Tibor Digana edited comment on SUREFIRE-1325 at 4/8/17 12:14 PM: - [~Bingoko] Having the elapsed time would help me too, but the memory consumption should be fixed after I introduce a new format of stream. The stream transfers data from forked jvm to Maven process. If you want to you can patch the elapsed time and open pull request in GitHub. was (Author: tibor17): [~Bingoko] Having the elapsed time would help me too, but the memory consumption should fixed after I introduce a new format of stream. The format transfers data from forked jvm to Maven process. If you want to you can patch the elapsed time and open pull request in GitHub. > Monitoring the testing memory consumption and printed with elapsed time > --- > > Key: SUREFIRE-1325 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1325 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin, process forking >Reporter: Bob Li > Labels: profiler > Original Estimate: 12h > Remaining Estimate: 12h > > As the user, the elapsed time for executing the test case is important, but I > think the memory consumption is also important. > I think the maven surefire could printed both of them for the user. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1328) Test should throw ClassCastException but doesn't
[ https://issues.apache.org/jira/browse/SUREFIRE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961800#comment-15961800 ] Tibor Digana commented on SUREFIRE-1328: [~Sywor] I do not understand your problem. What's wrong in this log?: [INFO] --- maven-surefire-plugin:2.19.1:test (default-test) @ surefireBug --- Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-junit4/2.19.1/surefire-junit4-2.19.1.pom Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-junit4/2.19.1/surefire-junit4-2.19.1.pom (0 B at 0.0 KB/sec) Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-junit4/2.19.1/surefire-junit4-2.19.1.jar Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-junit4/2.19.1/surefire-junit4-2.19.1.jar (0 B at 0.0 KB/sec) --- T E S T S --- Running TestUseCustomCollection Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.534 sec <<< FAILURE! - in TestUseCustomCollection testThatActualFails(TestUseCustomCollection) Time elapsed: 0.004 sec <<< ERROR! java.lang.ClassCastException: Item cannot be cast to WrongInterface at TestUseCustomCollection.testThatActualFails(TestUseCustomCollection.java:48) Results : Tests in error: TestUseCustomCollection.testThatActualFails:48 ClassCast Item cannot be cast t... Tests run: 2, Failures: 0, Errors: 1, Skipped: 0 [INFO] [INFO] BUILD FAILURE [INFO] > Test should throw ClassCastException but doesn't > > > Key: SUREFIRE-1328 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1328 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support, Maven Surefire Plugin >Affects Versions: 2.19.1 > Environment: Windows and Linux (Ubuntu 14.04); Java 1.8.0 111 and 112 > x64; junit 4.12; mockito 2.6.8; assertj 3.6.2 >Reporter: Ossian Petri > Attachments: surefireBug.zip > > > When using argument captor together with assertThat::isInstanceOf in the > example code that is provided an ClassCastException is expected. This > behavior can be seen when running the test from command line and as well from > Intellij which uses surefire plugin. However this code behaves predictably in > Eclipse since it has its own test executor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1328) Test should throw ClassCastException but doesn't
[
https://issues.apache.org/jira/browse/SUREFIRE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961801#comment-15961801
]
Tibor Digana commented on SUREFIRE-1328:
See {{target/surefire-reports/TEST-TestUseCustomCollection.xml}}.
The exception is in report.
java.lang.ClassCastException: Item cannot
be cast to WrongInterface
at
TestUseCustomCollection.testThatActualFails(TestUseCustomCollection.java:48)
> Test should throw ClassCastException but doesn't
>
>
> Key: SUREFIRE-1328
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1328
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: Windows and Linux (Ubuntu 14.04); Java 1.8.0 111 and 112
> x64; junit 4.12; mockito 2.6.8; assertj 3.6.2
>Reporter: Ossian Petri
> Attachments: surefireBug.zip
>
>
> When using argument captor together with assertThat::isInstanceOf in the
> example code that is provided an ClassCastException is expected. This
> behavior can be seen when running the test from command line and as well from
> Intellij which uses surefire plugin. However this code behaves predictably in
> Eclipse since it has its own test executor.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1287) Improve logging to understand why test run failed and report the right failed category
[ https://issues.apache.org/jira/browse/SUREFIRE-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961823#comment-15961823 ] Tibor Digana commented on SUREFIRE-1287: [~samarth.j...@gmail.com] [~samarthjain] [~jamestaylor] Pls try to use Surefire and Failsafe Version 2.20. You have to specify pluginRepository in your POM https://repository.apache.org/content/repositories/maven-1330/ We will remove this repo after three days. We improved stability of the plugins. > Improve logging to understand why test run failed and report the right failed > category > -- > > Key: SUREFIRE-1287 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1287 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Samarth Jain >Assignee: Tibor Digana > Fix For: Backlog > > > As part of our automated jenkins builds that run after every checkin, we have > been seeing a lot of these failures: > Failed to execute goal > org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:verify > (ParallelStatsEnabledTest) on project phoenix-core: There was a timeout or > other error in the fork > Sample run: > https://builds.apache.org/job/Phoenix-master/1420/console > Unfortunately that bit of error information doesn't really help. It would be > good to know why exactly the fork timed out or failed. What we do know is > that some of the tests in the Junit category ParallelStatsDisabledTest failed > to complete. However, failsafe incorrectly reports the failed category as the > first category that ran. In this case it happened to be > ParallelStatsEnabledTest. Also to note is the fact that failsafe kicks off > next category run even before all the tests in the current category have > finished. I am not sure if that is by design or a bug. > FYI, [~jamestaylor]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1267) Maven Surifire pluging fails with TesNG SoftAssert.
[ https://issues.apache.org/jira/browse/SUREFIRE-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961825#comment-15961825 ] Tibor Digana commented on SUREFIRE-1267: [~sumitsharma] The bottom of log is useless. Pls provide entire log. Check it out with Version 2.20. This version is available in plugin repository https://repository.apache.org/content/repositories/maven-1330/ and will be promoted soon. > Maven Surifire pluging fails with TesNG SoftAssert. > --- > > Key: SUREFIRE-1267 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1267 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.19.1 >Reporter: Sumit Sharma > > I am using Maven Surefire plugin with TestNG SoftAssert. When I am catching > any softassert in my Test case SureFire Plugin giving below error. I am using > sofAssert.assertAll() methode in my @Test Annotation. > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 57.062 s > [INFO] Finished at: 2016-08-01T16:30:26+05:30 > [INFO] Final Memory: 16M/220M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on > project Project: There are test failures. > [ERROR] > [ERROR] Please refer to C:\MavenTestNG\Project\target\surefire-reports for > the individual test results. > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1340) add a kind of progress status to surefire output
[
https://issues.apache.org/jira/browse/SUREFIRE-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962128#comment-15962128
]
Tibor Digana commented on SUREFIRE-1340:
[~romain.manni-bucau]
Pls explain me what you prefer more with this line:
{{[124/1254] normal output }}
Is it progress in the test set or text in JUnit Suite?
This:
{{Running ...Suite}}
{{[124/1226]}}
Or this:
{{Running ...Suite}}
{{FirstNestedTest: bla bla bla msg}}
{{SecondNestedTest: bla bla bla msg}}
> add a kind of progress status to surefire output
>
>
> Key: SUREFIRE-1340
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1340
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> ATM surefire executes tests but for big suites no way to know where we are in
> the execution exactly. What about adding a kind of line prefix showing it:
> {code}
> [124/1254] normal output
> [124/1254] another normal output
> [126/1254] another normal output after 2 tests finished
> ...
> {code}
> This would at least allow to know where we are. Idea would be to have a
> counter in the "executor" and just show it when there is something on
> stdout/stderr.
> Of course it will require a new configuration flag to activate it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (SUREFIRE-1328) Test should throw ClassCastException but doesn't
[ https://issues.apache.org/jira/browse/SUREFIRE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1328: -- Assignee: Tibor Digana > Test should throw ClassCastException but doesn't > > > Key: SUREFIRE-1328 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1328 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support, Maven Surefire Plugin >Affects Versions: 2.19.1 > Environment: Windows and Linux (Ubuntu 14.04); Java 1.8.0 111 and 112 > x64; junit 4.12; mockito 2.6.8; assertj 3.6.2 >Reporter: Ossian Petri >Assignee: Tibor Digana > Attachments: surefireBug.zip > > > When using argument captor together with assertThat::isInstanceOf in the > example code that is provided an ClassCastException is expected. This > behavior can be seen when running the test from command line and as well from > Intellij which uses surefire plugin. However this code behaves predictably in > Eclipse since it has its own test executor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1328) Test should throw ClassCastException but doesn't
[ https://issues.apache.org/jira/browse/SUREFIRE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1328: --- Attachment: 2017-04-10 13_09_48-surefireBug.jpg Verified on ASF side. > Test should throw ClassCastException but doesn't > > > Key: SUREFIRE-1328 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1328 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support, Maven Surefire Plugin >Affects Versions: 2.19.1 > Environment: Windows and Linux (Ubuntu 14.04); Java 1.8.0 111 and 112 > x64; junit 4.12; mockito 2.6.8; assertj 3.6.2 >Reporter: Ossian Petri >Assignee: Tibor Digana > Attachments: 2017-04-10 13_09_48-surefireBug.jpg, surefireBug.zip > > > When using argument captor together with assertThat::isInstanceOf in the > example code that is provided an ClassCastException is expected. This > behavior can be seen when running the test from command line and as well from > Intellij which uses surefire plugin. However this code behaves predictably in > Eclipse since it has its own test executor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1328) Test should throw ClassCastException but doesn't
[ https://issues.apache.org/jira/browse/SUREFIRE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962720#comment-15962720 ] Tibor Digana commented on SUREFIRE-1328: [~Sywor] I have aded jpg image with your project launched in IntelliJ IDEA and I see the same result. One test is successful and the other (testThatActuallyFails) fails with identical error. This sould be okay or? > Test should throw ClassCastException but doesn't > > > Key: SUREFIRE-1328 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1328 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support, Maven Surefire Plugin >Affects Versions: 2.19.1 > Environment: Windows and Linux (Ubuntu 14.04); Java 1.8.0 111 and 112 > x64; junit 4.12; mockito 2.6.8; assertj 3.6.2 >Reporter: Ossian Petri >Assignee: Tibor Digana > Attachments: 2017-04-10 13_09_48-surefireBug.jpg, surefireBug.zip > > > When using argument captor together with assertThat::isInstanceOf in the > example code that is provided an ClassCastException is expected. This > behavior can be seen when running the test from command line and as well from > Intellij which uses surefire plugin. However this code behaves predictably in > Eclipse since it has its own test executor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1328) Test should throw ClassCastException but doesn't
[
https://issues.apache.org/jira/browse/SUREFIRE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962743#comment-15962743
]
Tibor Digana commented on SUREFIRE-1328:
You have a problem with Eclipse.
Try to use identical sources from Jira.
And launch Junit in low level:
{{List = new
JUnitCore().run(TestUseCustomCollection.class).getFailures();}}
Evaluate it.
I think everything is correct with both tests because the first one "test" does
not have an assignment to {{WrongInterface}} and must not fail.
The problem is that you value in map has {{java.lang.Object}}, see
{{CustomCollection#put(String, Object)}}. From the point of view of Mockito
this type can be either Item or WrongInterface.
Since you passed {{new Item()}}, the type {{Item}} is not type of
{{WrongInterface}} the line fails on ClassCastException.
In the first test {{test()}} you do not have such assignment and therefore it
must not fail.
>From my point of view you have build and run different {{*.class}} files and
>not the sources you gave me.
As I said the result in IntelliJ IDEA is:
"test" is successful.
"testThatActualFails" fails
I would close this issue as user's error.
> Test should throw ClassCastException but doesn't
>
>
> Key: SUREFIRE-1328
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1328
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: Windows and Linux (Ubuntu 14.04); Java 1.8.0 111 and 112
> x64; junit 4.12; mockito 2.6.8; assertj 3.6.2
>Reporter: Ossian Petri
>Assignee: Tibor Digana
> Attachments: 2017-04-10 13_09_48-surefireBug.jpg, surefireBug.zip,
> test_eclipes.png, testThatActualFails_eclipes.png
>
>
> When using argument captor together with assertThat::isInstanceOf in the
> example code that is provided an ClassCastException is expected. This
> behavior can be seen when running the test from command line and as well from
> Intellij which uses surefire plugin. However this code behaves predictably in
> Eclipse since it has its own test executor.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1328) Test should throw ClassCastException but doesn't
[ https://issues.apache.org/jira/browse/SUREFIRE-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1328. -- Resolution: Not A Problem Feel free to reopen if it's a real issue. > Test should throw ClassCastException but doesn't > > > Key: SUREFIRE-1328 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1328 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support, Maven Surefire Plugin >Affects Versions: 2.19.1 > Environment: Windows and Linux (Ubuntu 14.04); Java 1.8.0 111 and 112 > x64; junit 4.12; mockito 2.6.8; assertj 3.6.2 >Reporter: Ossian Petri >Assignee: Tibor Digana > Attachments: 2017-04-10 13_09_48-surefireBug.jpg, surefireBug.zip, > test_eclipes.png, testThatActualFails_eclipes.png > > > When using argument captor together with assertThat::isInstanceOf in the > example code that is provided an ClassCastException is expected. This > behavior can be seen when running the test from command line and as well from > Intellij which uses surefire plugin. However this code behaves predictably in > Eclipse since it has its own test executor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963182#comment-15963182
]
Tibor Digana commented on SUREFIRE-1314:
[~mishail]
{{BeforeClass}} has nothing to do with {{Description.isTest()}}, see the JUnit
sources.
Such interceptors like before may fail and that's fatal error within JUnit. Ask
about it the JUnit team and they will tell you that they are not able to
instantiate test due to static code threw an exception. In general in Java
Reflection API you would not be able to instantiate a class if static code
fails.
This must be fatal error. This is maybe edge condition. JUnit should throw
InitializerError. This behavior could easily change from version to version of
JUnit library. Ask the JUnit team.
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963357#comment-15963357
]
Tibor Digana commented on SUREFIRE-1314:
[~mishail]
If it is so then it would be JUnit bug.
What version of junit you use?
Can you please try to make a research of JUnit, add listener, and evaluate this?
{{List = new JUnitCore().run(YourTest.class).getFailures();}}
It is very hard for me to help you if I do not see your project, but I think I
would do the same evaluation as you should do.
All we do is very similar to the above statement in Surefire, additionally we
add a listener to JUnitCore instance. We use standard JUnit facilities and
therefore talking about JUnit internals signals to me JUnit issue.
Pls investigate the code and let me know your findings. Through RunListener of
junit you will have an access to {{Description}} and you can check what the
method {{isTest()}} returns.
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1314:
--
Assignee: Tibor Digana
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>Assignee: Tibor Digana
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963463#comment-15963463
]
Tibor Digana commented on SUREFIRE-1314:
[~mishail]
Use another provider {{surefire-junit47}} in your project and let me know. You
use {{surefire-junit4}} by default.
{{JUnitCore}} was introduced in 4.7.
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>Assignee: Tibor Digana
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963484#comment-15963484
]
Tibor Digana commented on SUREFIRE-1314:
[~mishail]
After having a look in Surefire code, now I will explain why I think it is
JUnit issue and you should report a bug in GitHub.
The failures come from {{RunListener#testFailure( Failure failure )}}.
The description {{test(jiras.surefire1146.ErrorInBeforeClassTest)}} looks like
a test method, and the method {{isTest}} should return true.
Surefire must not make any guesses about description and must fully trust JUnit.
Therefore you should report bug against JUnit. I think this callback method
should not be called by JUnit at all.
I know junit committers, so you can link both tickets and I can participate
there. If junit comitters give me a valuable workaround we can continue. I will
temporarily close this issue.
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>Assignee: Tibor Digana
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1314.
--
Resolution: Not A Bug
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>Assignee: Tibor Digana
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963518#comment-15963518
]
Tibor Digana commented on SUREFIRE-1314:
[~mishail]
I want to understand what's going on. {{isTest==false}} is returned for the
class, right?
Please confirm that rerun did not run test method because BeforeClass threw
exception.
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>Assignee: Tibor Digana
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963528#comment-15963528
]
Tibor Digana commented on SUREFIRE-1314:
[~mishail]
JUnit is not implicitly designed for rerun.
We must start JUnit again and therefore BeforeClass is run again.
Simply you can rely on ClassLoader and start the code in static context instead
of in BeforeClass:
{code}
static {
e.g. start a connection here
}
{code}
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>Assignee: Tibor Digana
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963605#comment-15963605
]
Tibor Digana commented on SUREFIRE-1314:
ok, this is better. Not Surefire and not JUnit erroe.
You have to fi your bug in your test.
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>Assignee: Tibor Digana
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963803#comment-15963803
]
Tibor Digana commented on SUREFIRE-1314:
It is obviously bug in your static initializer.
Surround static code in try-catch and fix the bug.
Attach your real code to Jira; otherwise I have to close this issue.
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>Assignee: Tibor Digana
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963813#comment-15963813
]
Tibor Digana commented on SUREFIRE-1314:
[~mishail]
Focus on the message {{"Could not initialize class"}}. This refers to static
initializer code. You have to try-catch the code and discover the issue in
static code. The instance of the class {{ErrorInBeforeClassTest}} could not be
created, see reflection
{{at java.lang.reflect.Constructor.newInstance(Constructor.java:423)}}
{{at
org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:217)}}.
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>Assignee: Tibor Digana
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1314) rerunFailingTestsCount doesn't work for errors in BeforeClass methods
[
https://issues.apache.org/jira/browse/SUREFIRE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963816#comment-15963816
]
Tibor Digana commented on SUREFIRE-1314:
{code}
static {
try {
.. your static code ..
} catch (Throwable t) {
t.printStackTrace();
}
}
{code}
> rerunFailingTestsCount doesn't work for errors in BeforeClass methods
> -
>
> Key: SUREFIRE-1314
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1314
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Mikhail Stepura
>Assignee: Tibor Digana
>
> We're using {{surefire.rerunFailingTestsCoun}} property for our integration
> tests, and everything working fine when an error/failure happens in a test
> method (i.e. {{@Test}} ), and those test methods are re-executed later, as
> expected.
> But if an error happens in a {{BeforeClass}} class method, then those test
> classes are not re-executed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969259#comment-15969259
]
Tibor Digana commented on SUREFIRE-1302:
[~opeyrusse]
Can you enable {{-verbose:gc}} and tell me how slow the GC is?
Ping should be received within 20 seconds.
Please test your project with new version {{2.20}} which was released yesterday.
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: Backlog
>
> Attachments:
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1359) Corrupted stdin stream in forked JVM 1. See the dump file
[
https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969287#comment-15969287
]
Tibor Digana commented on SUREFIRE-1359:
[~binkley]
Corrupted stream was even in {{2.19.1}} but was not visible in logs. In old
version this could crash or hang the build process.
The new version will warn you with {{Corrupted stdin stream in forked JVM}}
with each particular JVM# only once on the console.
These dump files should not crash your tests now but we are making them more
visible now.
We report them because this is not our fault and we want the vendors of another
libraries to fix it. The entire problem is that the libraries log to native
{{System.out}} caught on JVM startup, or direct stream {{FileDescriptor.out}}
within the forked JVM.
> Corrupted stdin stream in forked JVM 1. See the dump file
> -
>
> Key: SUREFIRE-1359
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1359
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: JDK 1.8.0_121
> maven version 3.5.0
>Reporter: Brian Oxley
> Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream,
> 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml,
> hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt,
> TEST-hm.binkley.labs.GitInfoIT.xml,
> TEST-hm.binkley.labs.GreetingControllerIT.xml
>
>
> Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump
> file". Version 2.19.1 does not, and testing completes successfully.
> Project is here: https://github.com/binkley/sproingk.
> Run with "mvn clean verify".
> Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on
> Windows.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (SUREFIRE-1361) Buffering in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1361: -- Assignee: Tibor Digana > Buffering in StatelessXmlReporter > - > > Key: SUREFIRE-1361 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1361 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > > The StatelessXmlReporter could use BufferedOutputStream to reduce number of > I/O operations. This is relevant in cloud environments where I/O is an > expensive resource. > See this idea here: > https://github.com/jerrinot/maven-surefire/commit/c14adcd5dd5c90ff21fecb06dba371abbd047592#diff-8e45a39c93c604be350adf1af9a40f62R370 > Related to: https://issues.apache.org/jira/browse/SUREFIRE-1362 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (SUREFIRE-1362) Buffering in ConsoleOutputFileReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1362: -- Assignee: Tibor Digana > Buffering in ConsoleOutputFileReporter > -- > > Key: SUREFIRE-1362 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1362 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > > The ConsoleOutputFileReporter could use BufferedOutputStream to reduce number > of I/O operations. This is relevant in cloud environments where I/O is an > expensive resource. > See the idea here: > https://github.com/jerrinot/maven-surefire/commit/c14adcd5dd5c90ff21fecb06dba371abbd047592#diff-51e4b3861a0a31eb8479fbf2907911caR95 > Related to https://issues.apache.org/jira/browse/SUREFIRE-1361 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1362) Buffering in ConsoleOutputFileReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969293#comment-15969293 ] Tibor Digana commented on SUREFIRE-1362: Can you open pull request on the top of current HEAD? > Buffering in ConsoleOutputFileReporter > -- > > Key: SUREFIRE-1362 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1362 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > > The ConsoleOutputFileReporter could use BufferedOutputStream to reduce number > of I/O operations. This is relevant in cloud environments where I/O is an > expensive resource. > See the idea here: > https://github.com/jerrinot/maven-surefire/commit/c14adcd5dd5c90ff21fecb06dba371abbd047592#diff-51e4b3861a0a31eb8479fbf2907911caR95 > Related to https://issues.apache.org/jira/browse/SUREFIRE-1361 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1361) Buffering in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969292#comment-15969292 ] Tibor Digana commented on SUREFIRE-1361: Can you open pull request on the top of current HEAD? > Buffering in StatelessXmlReporter > - > > Key: SUREFIRE-1361 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1361 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > > The StatelessXmlReporter could use BufferedOutputStream to reduce number of > I/O operations. This is relevant in cloud environments where I/O is an > expensive resource. > See this idea here: > https://github.com/jerrinot/maven-surefire/commit/c14adcd5dd5c90ff21fecb06dba371abbd047592#diff-8e45a39c93c604be350adf1af9a40f62R370 > Related to: https://issues.apache.org/jira/browse/SUREFIRE-1362 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1362) Buffering in ConsoleOutputFileReporter
[
https://issues.apache.org/jira/browse/SUREFIRE-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969296#comment-15969296
]
Tibor Digana commented on SUREFIRE-1362:
Please run {{mvn -P run-its install}} build, cca 50 minutes to complete. All
ITs should pass.
> Buffering in ConsoleOutputFileReporter
> --
>
> Key: SUREFIRE-1362
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1362
> Project: Maven Surefire
> Issue Type: Improvement
>Reporter: Jaromir Hamala
>Assignee: Tibor Digana
>Priority: Minor
>
> The ConsoleOutputFileReporter could use BufferedOutputStream to reduce number
> of I/O operations. This is relevant in cloud environments where I/O is an
> expensive resource.
> See the idea here:
> https://github.com/jerrinot/maven-surefire/commit/c14adcd5dd5c90ff21fecb06dba371abbd047592#diff-51e4b3861a0a31eb8479fbf2907911caR95
> Related to https://issues.apache.org/jira/browse/SUREFIRE-1361
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1360) Option to disable properties dumping in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969307#comment-15969307 ] Tibor Digana commented on SUREFIRE-1360: [~jerrinot] This is possible but changing a lot of classes and maintaining reflection staff takes time in order to introduce a new config param. Would you do it by yourself in a new PR? Can we bind this feature to existing parameter or conbination of parameters? > Option to disable properties dumping in StatelessXmlReporter > > > Key: SUREFIRE-1360 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1360 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Jaromir Hamala >Priority: Minor > > I'd like to have an option to disable dumping (all?) properties into XML > reports. > Reasoning: > The same properties are repeated in 10,000's of XML test reports. > In many cases this is unnecessary. It's painful when a test environment has > I/O throttling - think of AWS with I/O burst credits. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969508#comment-15969508
]
Tibor Digana commented on SUREFIRE-1302:
[~opeyrusse]
I think we can use JMX {{GarbageCollectorMXBean}} and prolong the ping period
by the delay caused by GC.
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: Backlog
>
> Attachments:
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (SUREFIRE-1360) Option to disable properties dumping in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1360: -- Assignee: Tibor Digana > Option to disable properties dumping in StatelessXmlReporter > > > Key: SUREFIRE-1360 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1360 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > > I'd like to have an option to disable dumping (all?) properties into XML > reports. > Reasoning: > The same properties are repeated in 10,000's of XML test reports. > In many cases this is unnecessary. It's painful when a test environment has > I/O throttling - think of AWS with I/O burst credits. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1360) Option to disable properties dumping in StatelessXmlReporter
[
https://issues.apache.org/jira/browse/SUREFIRE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969555#comment-15969555
]
Tibor Digana commented on SUREFIRE-1360:
[~jerrinot]
Good News.
We do not have to create a new parameter. We can reuse the existing one and
support CSV. Please update Javadoc and documentation {{*.apt.vm}}.
{code}
@Parameter( property = "surefire.reportFormat", defaultValue = "brief" )
private String reportFormat;
{code}
See where {{"brief"}} is used. We rely on two values and therefore you will see
{{boolean}} sometimes. Please rework the code to e.g. {{Set}}.
I do not know how you want to call a new parameter value, e.g.
{{suppressSystemProperties}}.
> Option to disable properties dumping in StatelessXmlReporter
>
>
> Key: SUREFIRE-1360
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1360
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Jaromir Hamala
>Assignee: Tibor Digana
>Priority: Minor
>
> I'd like to have an option to disable dumping (all?) properties into XML
> reports.
> Reasoning:
> The same properties are repeated in 10,000's of XML test reports.
> In many cases this is unnecessary. It's painful when a test environment has
> I/O throttling - think of AWS with I/O burst credits.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1360) Option to disable properties dumping in StatelessXmlReporter
[
https://issues.apache.org/jira/browse/SUREFIRE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969558#comment-15969558
]
Tibor Digana commented on SUREFIRE-1360:
[~jerrinot]
I forgot to say that IT test should be written first, see
{{surefire-integration-tests}} module.
If you have question, just ask.
> Option to disable properties dumping in StatelessXmlReporter
>
>
> Key: SUREFIRE-1360
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1360
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Jaromir Hamala
>Assignee: Tibor Digana
>Priority: Minor
>
> I'd like to have an option to disable dumping (all?) properties into XML
> reports.
> Reasoning:
> The same properties are repeated in 10,000's of XML test reports.
> In many cases this is unnecessary. It's painful when a test environment has
> I/O throttling - think of AWS with I/O burst credits.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969571#comment-15969571
]
Tibor Digana commented on SUREFIRE-1302:
[~opeyrusse]
Can you help us and fix this issue in class {{ForkedBooter}}?
I am working on three other issues and we want to make release in April and
support JDK9.
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: Backlog
>
> Attachments:
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SUREFIRE-1363) Java 1.6 features @Override and Charset
Tibor Digana created SUREFIRE-1363: -- Summary: Java 1.6 features @Override and Charset Key: SUREFIRE-1363 URL: https://issues.apache.org/jira/browse/SUREFIRE-1363 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support, Junit 4.7+ (parallel) support, Junit 4.x support, Maven Failsafe Plugin, Maven Surefire Plugin, Maven Surefire Report Plugin, TestNG support Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 2.20.1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1363) Java 1.6 features @Override and Charset
[ https://issues.apache.org/jira/browse/SUREFIRE-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1363: --- Description: This is the branch with code changes https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=c47c6bbaf857c71a23f0623b552c0e7b7ab28b4c > Java 1.6 features @Override and Charset > --- > > Key: SUREFIRE-1363 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1363 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support, Junit 4.7+ (parallel) support, Junit > 4.x support, Maven Failsafe Plugin, Maven Surefire Plugin, Maven Surefire > Report Plugin, TestNG support >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.20.1 > > > This is the branch with code changes > https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=c47c6bbaf857c71a23f0623b552c0e7b7ab28b4c -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1363) Java 1.6 features @Override and Charset
[ https://issues.apache.org/jira/browse/SUREFIRE-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1363: --- Issue Type: Improvement (was: Bug) > Java 1.6 features @Override and Charset > --- > > Key: SUREFIRE-1363 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1363 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 3.x support, Junit 4.7+ (parallel) support, Junit > 4.x support, Maven Failsafe Plugin, Maven Surefire Plugin, Maven Surefire > Report Plugin, TestNG support >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.20.1 > > > This is the branch with code changes > https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=c47c6bbaf857c71a23f0623b552c0e7b7ab28b4c -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1359) Corrupted stdin stream in forked JVM 1. See the dump file
[
https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970085#comment-15970085
]
Tibor Digana commented on SUREFIRE-1359:
[~binkley]
Your attached report files do not have any failure and I made git clone of your
project and started the build {{mvn verify}}
{quote}
mvn verify
[WARNING] Source root doesn't exist:
d:\vcs\github\sproingk\target\generated-sources\annotations
[WARNING] Source root doesn't exist:
d:\vcs\github\sproingk\target\generated-test-sources\test-annotations
---
T E S T S
---
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
---
T E S T S
---
Running hm.binkley.labs.GitInfoIT
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/D:/.m2/repository/ch/qos/logback/logback-classic/1.1.11/logback-classic-1.1.11.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/D:/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type
[ch.qos.logback.classic.util.ContextSelectorStaticBinder]
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.997 sec - in
hm.binkley.labs.GitInfoIT
Running hm.binkley.labs.GreetingControllerIT
2017-04-15 21:09:31.536 WARN [bootstrap,,,] 21832 --- [ main]
o.s.c.n.a.ArchaiusAutoConfiguration : Netflix ConfigurationManager has
already been installed, unable to re-install
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.729 sec - in
hm.binkley.labs.GreetingControllerIT
Results :
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
{quote}
> Corrupted stdin stream in forked JVM 1. See the dump file
> -
>
> Key: SUREFIRE-1359
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1359
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: JDK 1.8.0_121
> maven version 3.5.0
>Reporter: Brian Oxley
> Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream,
> 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml,
> hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt,
> TEST-hm.binkley.labs.GitInfoIT.xml,
> TEST-hm.binkley.labs.GreetingControllerIT.xml
>
>
> Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump
> file". Version 2.19.1 does not, and testing completes successfully.
> Project is here: https://github.com/binkley/sproingk.
> Run with "mvn clean verify".
> Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on
> Windows.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1359) Corrupted stdin stream in forked JVM 1. See the dump file
[ https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970086#comment-15970086 ] Tibor Digana commented on SUREFIRE-1359: [~binkley] I used Maven 3.5.0. Can you reproduce it with the same version of Maven? > Corrupted stdin stream in forked JVM 1. See the dump file > - > > Key: SUREFIRE-1359 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1359 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 > Environment: JDK 1.8.0_121 > maven version 3.5.0 >Reporter: Brian Oxley > Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream, > 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml, > hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt, > TEST-hm.binkley.labs.GitInfoIT.xml, > TEST-hm.binkley.labs.GreetingControllerIT.xml > > > Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump > file". Version 2.19.1 does not, and testing completes successfully. > Project is here: https://github.com/binkley/sproingk. > Run with "mvn clean verify". > Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on > Windows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1359) Corrupted stdin stream in forked JVM 1. See the dump file
[
https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970098#comment-15970098
]
Tibor Digana commented on SUREFIRE-1359:
[~binkley]
Now I changed surefire version to 2.20 in properties and this is the result:
{quote}
mvn test
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Sproink 0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- git-commit-id-plugin:2.2.2:revision (default) @ sproingk ---
[INFO]
[INFO] --- jacoco-maven-plugin:0.7.9:prepare-agent (jacoco-initialize) @
sproingk ---
[INFO] argLine set to
-javaagent:D:\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.7.9\\org.jacoco.agent-0.7.9-runtime.jar=destfile=d:\\vcs\\github\\sproingk\\target\\jacoco.exec
[INFO]
[INFO] --- maven-dependency-plugin:3.0.0:sources (download-sources) @ sproingk
---
[INFO]
[INFO] --- maven-dependency-plugin:3.0.0:resolve (download-javadocs) @ sproingk
---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ sproingk
---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 4 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @ sproingk ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- kotlin-maven-plugin:1.1.1:compile (compile-kotlin) @ sproingk ---
[INFO] Kotlin Compiler version 1.1.1
[WARNING] Source root doesn't exist:
d:\vcs\github\sproingk\target\generated-sources\annotations
[INFO] Compiling Kotlin sources from [d:\vcs\github\sproingk\src\main\kotlin]
[INFO] Module name is sproingk
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
sproingk ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.6.1:testCompile (default-testCompile) @
sproingk ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- kotlin-maven-plugin:1.1.1:test-compile (test-compile-kotlin) @
sproingk ---
[INFO] Kotlin Compiler version 1.1.1
[WARNING] Source root doesn't exist:
d:\vcs\github\sproingk\target\generated-test-sources\test-annotations
[INFO] Compiling Kotlin sources from [d:\vcs\github\sproingk\src\test\kotlin]
[INFO] Module name is sproingk
[INFO]
[INFO] --- maven-surefire-plugin:2.20:test (default-test) @ sproingk ---
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 32.409 s
[INFO] Finished at: 2017-04-15T21:40:33+02:00
[INFO] Final Memory: 54M/482M
[INFO]
{quote}
> Corrupted stdin stream in forked JVM 1. See the dump file
> -
>
> Key: SUREFIRE-1359
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1359
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: JDK 1.8.0_121
> maven version 3.5.0
>Reporter: Brian Oxley
> Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream,
> 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml,
> hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt,
> TEST-hm.binkley.labs.GitInfoIT.xml,
> TEST-hm.binkley.labs.GreetingControllerIT.xml
>
>
> Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump
> file". Version 2.19.1 does not, and testing completes successfully.
> Project is here: https://github.com/binkley/sproingk.
> Run with "mvn clean verify".
> Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on
> Windows.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1359) Corrupted stdin stream in forked JVM 1. See the dump file
[ https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970099#comment-15970099 ] Tibor Digana commented on SUREFIRE-1359: I used Windows 7 and java version "1.8.0_121". > Corrupted stdin stream in forked JVM 1. See the dump file > - > > Key: SUREFIRE-1359 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1359 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 > Environment: JDK 1.8.0_121 > maven version 3.5.0 >Reporter: Brian Oxley > Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream, > 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml, > hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt, > TEST-hm.binkley.labs.GitInfoIT.xml, > TEST-hm.binkley.labs.GreetingControllerIT.xml > > > Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump > file". Version 2.19.1 does not, and testing completes successfully. > Project is here: https://github.com/binkley/sproingk. > Run with "mvn clean verify". > Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on > Windows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1359) Corrupted stdin stream in forked JVM 1. See the dump file
[
https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970102#comment-15970102
]
Tibor Digana commented on SUREFIRE-1359:
[~binkley]
>> it complains about "corrupted stdin stream", but the exit code is 0.
Does it mean that you did not see full log due to {{.mvn/jvm.config}}?
> Corrupted stdin stream in forked JVM 1. See the dump file
> -
>
> Key: SUREFIRE-1359
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1359
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: JDK 1.8.0_121
> maven version 3.5.0
>Reporter: Brian Oxley
> Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream,
> 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml,
> hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt,
> TEST-hm.binkley.labs.GitInfoIT.xml,
> TEST-hm.binkley.labs.GreetingControllerIT.xml
>
>
> Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump
> file". Version 2.19.1 does not, and testing completes successfully.
> Project is here: https://github.com/binkley/sproingk.
> Run with "mvn clean verify".
> Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on
> Windows.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (SUREFIRE-1359) Corrupted stdin stream in forked JVM 1. See the dump file
[ https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1359: -- Assignee: Tibor Digana > Corrupted stdin stream in forked JVM 1. See the dump file > - > > Key: SUREFIRE-1359 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1359 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 > Environment: JDK 1.8.0_121 > maven version 3.5.0 >Reporter: Brian Oxley >Assignee: Tibor Digana > Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream, > 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml, > hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt, > TEST-hm.binkley.labs.GitInfoIT.xml, > TEST-hm.binkley.labs.GreetingControllerIT.xml > > > Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump > file". Version 2.19.1 does not, and testing completes successfully. > Project is here: https://github.com/binkley/sproingk. > Run with "mvn clean verify". > Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on > Windows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1359) Corrupted stdin stream in forked JVM 1. See the dump file
[ https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1359. -- Resolution: Not A Bug > Corrupted stdin stream in forked JVM 1. See the dump file > - > > Key: SUREFIRE-1359 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1359 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 > Environment: JDK 1.8.0_121 > maven version 3.5.0 >Reporter: Brian Oxley >Assignee: Tibor Digana > Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream, > 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml, > hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt, > TEST-hm.binkley.labs.GitInfoIT.xml, > TEST-hm.binkley.labs.GreetingControllerIT.xml > > > Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump > file". Version 2.19.1 does not, and testing completes successfully. > Project is here: https://github.com/binkley/sproingk. > Run with "mvn clean verify". > Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on > Windows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[ https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1265: --- Fix Version/s: (was: Backlog) 2.20.1 > reuseForks=false fails on jdk-9-ea builds > - > > Key: SUREFIRE-1265 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1265 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Michael Musgrove >Assignee: Tibor Digana > Labels: jigsaw > Fix For: 2.20.1 > > Attachments: j9test.tar > > > When I run any surefire test (with reuseForks=false) that uses java.sql > classes on recent jdk-9 ea builds it fails with: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on > project maven-surefire-plugin-example: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: > java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException > -> [Help 1] > If I run it with reuseForks=true it works fine. > This problem was introduced in jdk build 9-ea+122 > (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw > team addressed: > d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1363) Java 1.6 features @Override and Charset
[ https://issues.apache.org/jira/browse/SUREFIRE-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1363. -- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=03ae55f4443aeca188edbdffa4e216c74063b33d > Java 1.6 features @Override and Charset > --- > > Key: SUREFIRE-1363 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1363 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 3.x support, Junit 4.7+ (parallel) support, Junit > 4.x support, Maven Failsafe Plugin, Maven Surefire Plugin, Maven Surefire > Report Plugin, TestNG support >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.20.1 > > > This is the branch with code changes > https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=c47c6bbaf857c71a23f0623b552c0e7b7ab28b4c -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1362) Buffering in ConsoleOutputFileReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1362: --- Fix Version/s: 2.20.1 > Buffering in ConsoleOutputFileReporter > -- > > Key: SUREFIRE-1362 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1362 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > Fix For: 2.20.1 > > > The ConsoleOutputFileReporter could use BufferedOutputStream to reduce number > of I/O operations. This is relevant in cloud environments where I/O is an > expensive resource. > See the idea here: > https://github.com/jerrinot/maven-surefire/commit/c14adcd5dd5c90ff21fecb06dba371abbd047592#diff-51e4b3861a0a31eb8479fbf2907911caR95 > Related to https://issues.apache.org/jira/browse/SUREFIRE-1361 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1361) Buffering in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1361: --- Fix Version/s: 2.20.1 > Buffering in StatelessXmlReporter > - > > Key: SUREFIRE-1361 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1361 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > Fix For: 2.20.1 > > > The StatelessXmlReporter could use BufferedOutputStream to reduce number of > I/O operations. This is relevant in cloud environments where I/O is an > expensive resource. > See this idea here: > https://github.com/jerrinot/maven-surefire/commit/c14adcd5dd5c90ff21fecb06dba371abbd047592#diff-8e45a39c93c604be350adf1af9a40f62R370 > Related to: https://issues.apache.org/jira/browse/SUREFIRE-1362 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1362) Buffering in ConsoleOutputFileReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1362: --- Component/s: Maven Surefire Plugin Maven Failsafe Plugin > Buffering in ConsoleOutputFileReporter > -- > > Key: SUREFIRE-1362 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1362 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > Fix For: 2.20.1 > > > The ConsoleOutputFileReporter could use BufferedOutputStream to reduce number > of I/O operations. This is relevant in cloud environments where I/O is an > expensive resource. > See the idea here: > https://github.com/jerrinot/maven-surefire/commit/c14adcd5dd5c90ff21fecb06dba371abbd047592#diff-51e4b3861a0a31eb8479fbf2907911caR95 > Related to https://issues.apache.org/jira/browse/SUREFIRE-1361 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1361) Buffering in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1361. -- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=9c0025ed53d70c06279fef6c0fc30a54aeeab27b > Buffering in StatelessXmlReporter > - > > Key: SUREFIRE-1361 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1361 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > Fix For: 2.20.1 > > > The StatelessXmlReporter could use BufferedOutputStream to reduce number of > I/O operations. This is relevant in cloud environments where I/O is an > expensive resource. > See this idea here: > https://github.com/jerrinot/maven-surefire/commit/c14adcd5dd5c90ff21fecb06dba371abbd047592#diff-8e45a39c93c604be350adf1af9a40f62R370 > Related to: https://issues.apache.org/jira/browse/SUREFIRE-1362 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1362) Buffering in ConsoleOutputFileReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1362. -- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=9c0025ed53d70c06279fef6c0fc30a54aeeab27b > Buffering in ConsoleOutputFileReporter > -- > > Key: SUREFIRE-1362 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1362 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > Fix For: 2.20.1 > > > The ConsoleOutputFileReporter could use BufferedOutputStream to reduce number > of I/O operations. This is relevant in cloud environments where I/O is an > expensive resource. > See the idea here: > https://github.com/jerrinot/maven-surefire/commit/c14adcd5dd5c90ff21fecb06dba371abbd047592#diff-51e4b3861a0a31eb8479fbf2907911caR95 > Related to https://issues.apache.org/jira/browse/SUREFIRE-1361 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1361) Buffering in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1361: --- Component/s: Maven Failsafe Plugin > Buffering in StatelessXmlReporter > - > > Key: SUREFIRE-1361 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1361 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > Fix For: 2.20.1 > > > The StatelessXmlReporter could use BufferedOutputStream to reduce number of > I/O operations. This is relevant in cloud environments where I/O is an > expensive resource. > See this idea here: > https://github.com/jerrinot/maven-surefire/commit/c14adcd5dd5c90ff21fecb06dba371abbd047592#diff-8e45a39c93c604be350adf1af9a40f62R370 > Related to: https://issues.apache.org/jira/browse/SUREFIRE-1362 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SUREFIRE-1364) Report XML should contain system properties of forked JVM
Tibor Digana created SUREFIRE-1364: -- Summary: Report XML should contain system properties of forked JVM Key: SUREFIRE-1364 URL: https://issues.apache.org/jira/browse/SUREFIRE-1364 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 2.20.1 Currently testing in forked JVM means that report XML contains system properties of Maven process. Each test class executed in forked JVM should emit system properties of that JVM on startup. In-Plugin process (forkCount=0 or forkMode=never) should again keep own properties of master process. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1360) Option to disable properties dumping in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970994#comment-15970994 ] Tibor Digana commented on SUREFIRE-1360: [~jerrinot] I created SUREFIRE-1364 and almost completed it. We can fix this issue on the top of SUREFIRE-1364. > Option to disable properties dumping in StatelessXmlReporter > > > Key: SUREFIRE-1360 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1360 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > > I'd like to have an option to disable dumping (all?) properties into XML > reports. > Reasoning: > The same properties are repeated in 10,000's of XML test reports. > In many cases this is unnecessary. It's painful when a test environment has > I/O throttling - think of AWS with I/O burst credits. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[
https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15973502#comment-15973502
]
Tibor Digana commented on SUREFIRE-1265:
[~mmusgrov]
[~jpoth]
Can you extract all jar files which should appear on classpath of tests and
check it again if they contain {{module-info.class}}?
{{module-info.class}} is produced by javac.
> reuseForks=false fails on jdk-9-ea builds
> -
>
> Key: SUREFIRE-1265
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1265
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Musgrove
>Assignee: Tibor Digana
> Labels: jigsaw
> Fix For: 2.20.1
>
> Attachments: j9test.tar
>
>
> When I run any surefire test (with reuseForks=false) that uses java.sql
> classes on recent jdk-9 ea builds it fails with:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project maven-surefire-plugin-example: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed:
> java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException
> -> [Help 1]
> If I run it with reuseForks=true it works fine.
> This problem was introduced in jdk build 9-ea+122
> (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw
> team addressed:
> d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1365) Allow environment variables to be read from a file, instead of set as a Map
[
https://issues.apache.org/jira/browse/SUREFIRE-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15973802#comment-15973802
]
Tibor Digana commented on SUREFIRE-1365:
[~dariusx]
I would like to reuse existing config parameter instead of introducing a new
one.
Do you think it would be possible in current version 2.20?
Otherwise we should think of plugin extension in version 3.0.0-alpha-x:
{code}
{code}
> Allow environment variables to be read from a file, instead of set as a Map
> ---
>
> Key: SUREFIRE-1365
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1365
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Darius Cooper
>Priority: Minor
>
> With 12-factors apps and deployment on platforms like OpenShift, there a new
> push on using Environment Variables for configuration. When running
> Integration tests with Failsafe, it would be nice to set the same variables
> as will be set to the target environment.
> Often, there's a file that contains the variables in a key-value pair format,
> just like a properties file. It would be nice to be able to read that same
> file in while setting environment variables for Failsafe and also when
> deploying.
> (There may be some type of simple file-formatting differences, but that's
> typically easy to handle in an automated way.)
> failsafe:integration-test supports an "environmentVariables" parameter. It
> would nice if it could support an "environmentVariablesFile" parameter that
> allowed a simple properties-style file to be read in an set as environment
> variables.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1365) Allow environment variables to be read from a file, instead of set as a Map
[ https://issues.apache.org/jira/browse/SUREFIRE-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1365: --- Fix Version/s: 3.0-RC1 3.0 > Allow environment variables to be read from a file, instead of set as a Map > --- > > Key: SUREFIRE-1365 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1365 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Darius Cooper >Assignee: Tibor Digana >Priority: Minor > Fix For: 3.0, 3.0-RC1 > > > With 12-factors apps and deployment on platforms like OpenShift, there a new > push on using Environment Variables for configuration. When running > Integration tests with Failsafe, it would be nice to set the same variables > as will be set to the target environment. > Often, there's a file that contains the variables in a key-value pair format, > just like a properties file. It would be nice to be able to read that same > file in while setting environment variables for Failsafe and also when > deploying. > (There may be some type of simple file-formatting differences, but that's > typically easy to handle in an automated way.) > failsafe:integration-test supports an "environmentVariables" parameter. It > would nice if it could support an "environmentVariablesFile" parameter that > allowed a simple properties-style file to be read in an set as environment > variables. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (SUREFIRE-1365) Allow environment variables to be read from a file, instead of set as a Map
[ https://issues.apache.org/jira/browse/SUREFIRE-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1365: -- Assignee: Tibor Digana > Allow environment variables to be read from a file, instead of set as a Map > --- > > Key: SUREFIRE-1365 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1365 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Darius Cooper >Assignee: Tibor Digana >Priority: Minor > Fix For: 3.0, 3.0-RC1 > > > With 12-factors apps and deployment on platforms like OpenShift, there a new > push on using Environment Variables for configuration. When running > Integration tests with Failsafe, it would be nice to set the same variables > as will be set to the target environment. > Often, there's a file that contains the variables in a key-value pair format, > just like a properties file. It would be nice to be able to read that same > file in while setting environment variables for Failsafe and also when > deploying. > (There may be some type of simple file-formatting differences, but that's > typically easy to handle in an automated way.) > failsafe:integration-test supports an "environmentVariables" parameter. It > would nice if it could support an "environmentVariablesFile" parameter that > allowed a simple properties-style file to be read in an set as environment > variables. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1302:
---
Hi Olivier,
I think configurable ping timeout may not necessarily save our soul.
If you think in terms of accuracy of timers in Maven process and forked
jvm, and GC this would lead to pretty long timeour, e.g. 30 or 60 seconds.
The Jenkins scheduler is faster, cca 5 sec and git clone is fast as well.
If we could synchronize both timers, we would do much better job. Include
JMX which would prolong the period checking by GC period when Maven process
is supposed to be idle or dead.
My problem with adding configuration parameter is a conflict with Version
3.0.
In 3.0 w have an ambition to customize the parameters with a programmatic
extension per parameter.
Add more and more parameters would delay 3.0 release and means having
unhappy users.
Version 3.0 has this ambition of extensions, requested by user group,
compatibility with Maven 3.0.x and JUnit 5 provider.
All of these are in progress in our branches.
Our PING code is simple. It is located in ForkedBooter.java.
There are two timers. Our ping timer has fixed rate scheduler. This timer
has period of 20 seconds. I think we can make much better code if we try to
synchronize Maven process ping with forked JVM at rate of 1 second. The
timer should be tolerant to GC pauses.
What is the location of long GC pauses? Is it forked JVM or Maven process?
If it is Maven process then I am afraid we cannot do anything about it.
If it is forked JVM, killing jvm itself is up to ForkedBooter running in
forked jvm and the code can be tolerant.
What happens if we have e.g. 1 second timer and GC pauses also this timer?
Would it invoke all elapsed events right after the GC has finished? We
should write the last tick of timer and counter of GC and retrieve delay
from JMX if counter has been incremented. I would say the period of 20
seconds of idle status should be prolonged internally and counting the
period restarted after PING has been received from Maven process which is
the synchronization.
On Wed, Apr 19, 2017 at 10:46 AM, Olivier Peyrusse (JIRA)
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: Backlog
>
> Attachments:
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975587#comment-15975587
]
Tibor Digana commented on SUREFIRE-1302:
[~opeyrusse]
Sooner or later we will use sockets and not these standard output and input
streams.
We have to provide the users with fallback.
Then this dump file would not contain GC logs because it will be found in
{{target/surefire-reports/TEST-null.txt}}.
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: Backlog
>
> Attachments:
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[
https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976142#comment-15976142
]
Tibor Digana commented on SUREFIRE-1265:
[~mmusgrov]
[~jpoth]
[~rfscholte]
I fixed this bug by passing platform ClassLoader to IsolatedClassLoader.
I will provide a branch to code review on Maven Dev Mailing List and then push
it to master.
{code}
parent = (ClassLoader) ClassLoader.class.getMethod( "getPlatformClassLoader"
).invoke( null )
new IsolatedClassLoader( parent, childDelegation, roleName );
{code}
> reuseForks=false fails on jdk-9-ea builds
> -
>
> Key: SUREFIRE-1265
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1265
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Musgrove
>Assignee: Tibor Digana
> Labels: jigsaw
> Fix For: 2.20.1
>
> Attachments: j9test.tar
>
>
> When I run any surefire test (with reuseForks=false) that uses java.sql
> classes on recent jdk-9 ea builds it fails with:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project maven-surefire-plugin-example: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed:
> java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException
> -> [Help 1]
> If I run it with reuseForks=true it works fine.
> This problem was introduced in jdk build 9-ea+122
> (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw
> team addressed:
> d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[ https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1265. -- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=cba4adb1b93002c5b4bb2d2f22f461cc53bd8738 > reuseForks=false fails on jdk-9-ea builds > - > > Key: SUREFIRE-1265 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1265 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Michael Musgrove >Assignee: Tibor Digana > Labels: jigsaw > Fix For: 2.20.1 > > Attachments: j9test.tar > > > When I run any surefire test (with reuseForks=false) that uses java.sql > classes on recent jdk-9 ea builds it fails with: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on > project maven-surefire-plugin-example: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: > java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException > -> [Help 1] > If I run it with reuseForks=true it works fine. > This problem was introduced in jdk build 9-ea+122 > (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw > team addressed: > d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1302:
---
Fix Version/s: (was: Backlog)
2.20.1
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments:
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SUREFIRE-1366) mvn javadoc:javadoc fails on Javadoc syntax with JDK 1.8
Tibor Digana created SUREFIRE-1366: -- Summary: mvn javadoc:javadoc fails on Javadoc syntax with JDK 1.8 Key: SUREFIRE-1366 URL: https://issues.apache.org/jira/browse/SUREFIRE-1366 Project: Maven Surefire Issue Type: Task Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 2.20.1 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:javadoc (default-cli) on project surefire-logger-api: An error has occurred in JavaDocs report generation: [ERROR] Exit code: 1 - ConsoleLogger.java:24: error: self-closing element not allowed [ERROR] * [ERROR]^ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1360) Option to disable properties dumping in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979866#comment-15979866 ] Tibor Digana commented on SUREFIRE-1360: [~jerrinot] Do you have spare time during this Weekend to work on this? We can do it together in one pull request. > Option to disable properties dumping in StatelessXmlReporter > > > Key: SUREFIRE-1360 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1360 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > > I'd like to have an option to disable dumping (all?) properties into XML > reports. > Reasoning: > The same properties are repeated in 10,000's of XML test reports. > In many cases this is unnecessary. It's painful when a test environment has > I/O throttling - think of AWS with I/O burst credits. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1366) mvn javadoc:javadoc fails on Javadoc syntax with JDK 1.8
[
https://issues.apache.org/jira/browse/SUREFIRE-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980319#comment-15980319
]
Tibor Digana commented on SUREFIRE-1366:
I found out warnings and errors while cutting the release {{version 2.20}} with
{{JDK 8}} last time.
I am glad that compiler can check javadoc with JDK 8. I configured rule
{{requireJavaVersion}} in {{maven-enforcer-plugin}} to {{[1.8.0,)}}.
Without this fix a documentation text in some MOJO parameter was not shown in
HTML.
> mvn javadoc:javadoc fails on Javadoc syntax with JDK 1.8
>
>
> Key: SUREFIRE-1366
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1366
> Project: Maven Surefire
> Issue Type: Task
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:javadoc (default-cli) on
> project surefire-logger-api: An error has occurred in JavaDocs report
> generation:
> [ERROR] Exit code: 1 - ConsoleLogger.java:24: error: self-closing element not
> allowed
> [ERROR] *
> [ERROR]^
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1366) mvn javadoc:javadoc fails on Javadoc syntax with JDK 1.8
[ https://issues.apache.org/jira/browse/SUREFIRE-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1366: --- Labels: documentation javadoc (was: ) > mvn javadoc:javadoc fails on Javadoc syntax with JDK 1.8 > > > Key: SUREFIRE-1366 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1366 > Project: Maven Surefire > Issue Type: Task >Reporter: Tibor Digana >Assignee: Tibor Digana > Labels: documentation, javadoc > Fix For: 2.20.1 > > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:javadoc (default-cli) on > project surefire-logger-api: An error has occurred in JavaDocs report > generation: > [ERROR] Exit code: 1 - ConsoleLogger.java:24: error: self-closing element not > allowed > [ERROR] * > [ERROR]^ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1366) mvn javadoc:javadoc fails on Javadoc syntax with JDK 1.8
[
https://issues.apache.org/jira/browse/SUREFIRE-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980319#comment-15980319
]
Tibor Digana edited comment on SUREFIRE-1366 at 4/23/17 8:45 AM:
-
I found out warnings and errors while cutting the release {{version 2.20}} with
{{JDK 8}} last time.
I am glad that compiler can check javadoc with JDK 8. I configured rule
{{requireJavaVersion}} in {{maven-enforcer-plugin}} to {{[1.8.0,)}}.
Without this fix a documentation text in some MOJO parameter was not shown in
HTML and {{mvn site}} would crash on JDK 8.
was (Author: tibor17):
I found out warnings and errors while cutting the release {{version 2.20}} with
{{JDK 8}} last time.
I am glad that compiler can check javadoc with JDK 8. I configured rule
{{requireJavaVersion}} in {{maven-enforcer-plugin}} to {{[1.8.0,)}}.
Without this fix a documentation text in some MOJO parameter was not shown in
HTML.
> mvn javadoc:javadoc fails on Javadoc syntax with JDK 1.8
>
>
> Key: SUREFIRE-1366
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1366
> Project: Maven Surefire
> Issue Type: Task
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Labels: documentation, javadoc
> Fix For: 2.20.1
>
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:javadoc (default-cli) on
> project surefire-logger-api: An error has occurred in JavaDocs report
> generation:
> [ERROR] Exit code: 1 - ConsoleLogger.java:24: error: self-closing element not
> allowed
> [ERROR] *
> [ERROR]^
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15981827#comment-15981827
]
Tibor Digana commented on SUREFIRE-1147:
[~chtimi59]
I think the issue is caused by implementation of class {{LogicalStream}}
because it keeps byte stream of std output in memory until the test-set has
completed.
How do you see this issue?
Have overcome this issue other way around?
> Unbounded memory usage when running MANY tests
> --
>
> Key: SUREFIRE-1147
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1147
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.18.1
> Environment: win7, jdk 8u25, mvn 3.2.5
>Reporter: Laurent Claisse
>Assignee: Tibor Digana
> Fix For: Backlog
>
> Attachments: surefire-allocation-traces.png, surefire-leak2.png,
> surefire-leak3.png, surefire-leak.png
>
>
> I'm writing concurrency tests, checking that this thing is reproducible, that
> other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to
> reproduce the leak, the test project is here:
> https://github.com/vandekeiser/parallel-stream-fork-join-pool)
> I see in VisualVM that the culprit is WrappedReportEntry, which indirectly
> holds references to lots of byte[] and char[] (allocation traces and heap
> dump pics are included in attachment)
> I forked and patched maven-surefire-common, and that makes the leak go. I had
> to replace WrappedReportEntry.original by a singleton fake ReportEntry.
> Bebefore that i had replaced
> Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a
> NullOutputStream and the leak was lesser but still here.
> My fork of maven-surefire-common is there:
> https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common.
> It IS a patch so i checked the patch checkbox in the issue reporter, but it
> is NOT intended to be distributed of course since it is very brutal and basic.
> Also in my test project i explicitly deactivated reporting, but that doesn't
> make the reporting leak go away at all:
> true
> false
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SUREFIRE-1367) System Output and Error should be reported in parallel JUnit tests if Assumption fails,
Tibor Digana created SUREFIRE-1367: -- Summary: System Output and Error should be reported in parallel JUnit tests if Assumption fails, Key: SUREFIRE-1367 URL: https://issues.apache.org/jira/browse/SUREFIRE-1367 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 2.20.1 Std/Out/Err is normally reported in TEST-*.xml and *-output.txt while executing JUnit tests in a single thread and tests fail on JUnit Assumption. In parallel execution the Std/Out/Err is completely lost. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1367) System Output and Error should be reported in parallel JUnit tests if Assumption fails.
[ https://issues.apache.org/jira/browse/SUREFIRE-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1367: --- Summary: System Output and Error should be reported in parallel JUnit tests if Assumption fails. (was: System Output and Error should be reported in parallel JUnit tests if Assumption fails,) > System Output and Error should be reported in parallel JUnit tests if > Assumption fails. > --- > > Key: SUREFIRE-1367 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1367 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.20.1 > > > Std/Out/Err is normally reported in TEST-*.xml and *-output.txt while > executing JUnit tests in a single thread and tests fail on JUnit Assumption. > In parallel execution the Std/Out/Err is completely lost. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1360) Option to disable properties dumping in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1360: --- Yes, I have branch SUREFIRE-1364. We can fork it to new branch SUREFIRE-1360 and continue there. On Tue, Apr 25, 2017 at 3:51 PM, Jaromir Hamala (JIRA) > Option to disable properties dumping in StatelessXmlReporter > > > Key: SUREFIRE-1360 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1360 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Tibor Digana >Priority: Minor > > I'd like to have an option to disable dumping (all?) properties into XML > reports. > Reasoning: > The same properties are repeated in 10,000's of XML test reports. > In many cases this is unnecessary. It's painful when a test environment has > I/O throttling - think of AWS with I/O burst credits. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1368) Not very informative fatal exit from testing - missing quotation in generated execution command
[
https://issues.apache.org/jira/browse/SUREFIRE-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986200#comment-15986200
]
Tibor Digana commented on SUREFIRE-1368:
{{What is ofcourse interesting, why v. 2.19.1 appears to be v. 2.15 in build.}}
This cannot happen. You have wrong configuration. Isolate the problem in
trivial POM and project and attach it to Jira.
Try version {{2.20}}.
> Not very informative fatal exit from testing - missing quotation in generated
> execution command
> ---
>
> Key: SUREFIRE-1368
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1368
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.19.1
> Environment: Windows 10
>Reporter: Seweryn Habdank-Wojewodzki
>
> Dears,
> I am starting build mvn -X -e clean install which includes test written using
> TestNG framework v. 6.8.8.
> There comes following information:
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> logviewerservice-test ---
> [INFO] Surefire report directory:
> C:\StorageSpace\Projects\clj_project\logviewerservice-master\logviewerservice-test\target\surefire-reports
> ---
> T E S T S
> ---
> Das System kann den angegebenen Pfad nicht finden.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
> project logviewerservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> The "Das System kann den angegebenen Pfad nicht finden." means, that given
> system path cannot be found.
> 1. Why mvn uses console language and not English?
> 2. Error message does not state which path cannot be found, so it makes
> impossible to solve the problem, as testing uses many different paths.
> 3. Everything happend before even target/surefire-reports directory is
> created.
> Can you help with that issue?
> The configuration is simple:
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> What is ofcourse interesting, why v. 2.19.1 appears to be v. 2.15 in build.
> Errors and exceptions are below:
> [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
> surefire-api-2.15.jar test-classes classes
> ... (bunch of jars)
> surefire-testng-utils-2.15.jar surefire-grouper-2.15.jar
> surefire-testng-2.15.jar common-java5-2.15.jar
> Forking command line: cmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> Das System kann den angegebenen Pfad nicht finden.
> [ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test)
> on project myservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> 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.apa
[jira] [Assigned] (SUREFIRE-1368) Not very informative fatal exit from testing - missing quotation in generated execution command
[
https://issues.apache.org/jira/browse/SUREFIRE-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1368:
--
Assignee: Tibor Digana
> Not very informative fatal exit from testing - missing quotation in generated
> execution command
> ---
>
> Key: SUREFIRE-1368
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1368
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.19.1
> Environment: Windows 10
>Reporter: Seweryn Habdank-Wojewodzki
>Assignee: Tibor Digana
>
> Dears,
> I am starting build {{mvn -X -e clean install}} which includes test written
> using TestNG framework v. 6.8.8.
> There comes following information:
> {noformat}
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> logviewerservice-test ---
> [INFO] Surefire report directory:
> C:\StorageSpace\Projects\clj_project\logviewerservice-master\logviewerservice-test\target\surefire-reports
> ---
> T E S T S
> ---
> Das System kann den angegebenen Pfad nicht finden.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
> project logviewerservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> {noformat}
> The "Das System kann den angegebenen Pfad nicht finden." means, that given
> system path cannot be found.
> 1. Why mvn uses console language and not English?
> 2. Error message does not state which path cannot be found, so it makes
> impossible to solve the problem, as testing uses many different paths.
> 3. Everything happend before even target/surefire-reports directory is
> created.
> Can you help with that issue?
> The configuration is simple:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> {code}
> What is ofcourse interesting, why v. 2.19.1 appears to be v. 2.15 in build.
> Errors and exceptions are below:
> {noformat}
> [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
> surefire-api-2.15.jar test-classes classes
> ... (bunch of jars)
> surefire-testng-utils-2.15.jar surefire-grouper-2.15.jar
> surefire-testng-2.15.jar common-java5-2.15.jar
> Forking command line: cmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> Das System kann den angegebenen Pfad nicht finden.
> [ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test)
> on project myservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> 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.intern
[jira] [Closed] (SUREFIRE-1368) Not very informative fatal exit from testing - missing quotation in generated execution command
[
https://issues.apache.org/jira/browse/SUREFIRE-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1368.
--
Resolution: Cannot Reproduce
Type {{System.out.println(System.getProperty("java.library.path"));}} in your
code.
Go to console or {{target/surefire-reports/MyTest-output.txt}} of your test
where you printed the property, and configure the plugin like this:
{code}
"-Djava.library.path=C:/Program Files (x86)/Foo/DLL"
{code}
One can wee {{C:/Program Files (x86)/Foo/DLL}} in console logs.
> Not very informative fatal exit from testing - missing quotation in generated
> execution command
> ---
>
> Key: SUREFIRE-1368
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1368
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.19.1
> Environment: Windows 10
>Reporter: Seweryn Habdank-Wojewodzki
>Assignee: Tibor Digana
>
> Dears,
> I am starting build {{mvn -X -e clean install}} which includes test written
> using TestNG framework v. 6.8.8.
> There comes following information:
> {noformat}
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> logviewerservice-test ---
> [INFO] Surefire report directory:
> C:\StorageSpace\Projects\clj_project\logviewerservice-master\logviewerservice-test\target\surefire-reports
> ---
> T E S T S
> ---
> Das System kann den angegebenen Pfad nicht finden.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
> project logviewerservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> {noformat}
> The "Das System kann den angegebenen Pfad nicht finden." means, that given
> system path cannot be found.
> 1. Why mvn uses console language and not English?
> 2. Error message does not state which path cannot be found, so it makes
> impossible to solve the problem, as testing uses many different paths.
> 3. Everything happend before even target/surefire-reports directory is
> created.
> Can you help with that issue?
> The configuration is simple:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> {code}
> What is ofcourse interesting, why v. 2.19.1 appears to be v. 2.15 in build.
> Errors and exceptions are below:
> {noformat}
> [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
> surefire-api-2.15.jar test-classes classes
> ... (bunch of jars)
> surefire-testng-utils-2.15.jar surefire-grouper-2.15.jar
> surefire-testng-2.15.jar common-java5-2.15.jar
> Forking command line: cmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> Das System kann den angegebenen Pfad nicht finden.
> [ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test)
> on project myservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> 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.
[jira] [Comment Edited] (SUREFIRE-1368) Not very informative fatal exit from testing - missing quotation in generated execution command
[
https://issues.apache.org/jira/browse/SUREFIRE-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986371#comment-15986371
]
Tibor Digana edited comment on SUREFIRE-1368 at 4/27/17 11:07 AM:
--
Type {{System.out.println(System.getProperty("java.library.path"));}} in your
code.
Go to console or {{target/surefire-reports/MyTest-output.txt}} of your test
where you printed the property, and configure the plugin like this:
{code}
"-Djava.library.path=C:/Program Files (x86)/Foo/DLL"
{code}
One can see {{C:/Program Files (x86)/Foo/DLL}} in console logs.
was (Author: tibor17):
Type {{System.out.println(System.getProperty("java.library.path"));}} in your
code.
Go to console or {{target/surefire-reports/MyTest-output.txt}} of your test
where you printed the property, and configure the plugin like this:
{code}
"-Djava.library.path=C:/Program Files (x86)/Foo/DLL"
{code}
One can wee {{C:/Program Files (x86)/Foo/DLL}} in console logs.
> Not very informative fatal exit from testing - missing quotation in generated
> execution command
> ---
>
> Key: SUREFIRE-1368
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1368
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.19.1
> Environment: Windows 10
>Reporter: Seweryn Habdank-Wojewodzki
>Assignee: Tibor Digana
>
> Dears,
> I am starting build {{mvn -X -e clean install}} which includes test written
> using TestNG framework v. 6.8.8.
> There comes following information:
> {noformat}
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> logviewerservice-test ---
> [INFO] Surefire report directory:
> C:\StorageSpace\Projects\clj_project\logviewerservice-master\logviewerservice-test\target\surefire-reports
> ---
> T E S T S
> ---
> Das System kann den angegebenen Pfad nicht finden.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
> project logviewerservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> {noformat}
> The "Das System kann den angegebenen Pfad nicht finden." means, that given
> system path cannot be found.
> 1. Why mvn uses console language and not English?
> 2. Error message does not state which path cannot be found, so it makes
> impossible to solve the problem, as testing uses many different paths.
> 3. Everything happend before even target/surefire-reports directory is
> created.
> Can you help with that issue?
> The configuration is simple:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> {code}
> What is ofcourse interesting, why v. 2.19.1 appears to be v. 2.15 in build.
> Errors and exceptions are below:
> {noformat}
> [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
> surefire-api-2.15.jar test-classes classes
> ... (bunch of jars)
> surefire-testng-utils-2.15.jar surefire-grouper-2.15.jar
> surefire-testng-2.15.jar common-java5-2.15.jar
> Forking command line: cmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> Das System kann den angegebenen Pfad nicht finden.
> [ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test)
> on project myservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\m
[jira] [Commented] (SUREFIRE-1368) Not very informative fatal exit from testing - missing quotation in generated execution command
[
https://issues.apache.org/jira/browse/SUREFIRE-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989493#comment-15989493
]
Tibor Digana commented on SUREFIRE-1368:
[~habdank]
It is always difficult with integration tools. Every change in POM and CI
should be verified.
Can you tell me if version {{2.20}} printed another error?
Do you still see the old version {{2.15}}?
{[ [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar}}
I plan to make some changes which includes printing error message and not the
stack trace, unless you enable it via {{mvn -e}}.
This error happened before forked JVM started. The command is in console and
the jdk path as system property was not defined {{ [ERROR] Command wascmd.exe
/X /C "${jdk180.path}\bin\java}}
> Not very informative fatal exit from testing - missing quotation in generated
> execution command
> ---
>
> Key: SUREFIRE-1368
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1368
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.19.1
> Environment: Windows 10
>Reporter: Seweryn Habdank-Wojewodzki
>Assignee: Tibor Digana
>
> Dears,
> I am starting build {{mvn -X -e clean install}} which includes test written
> using TestNG framework v. 6.8.8.
> There comes following information:
> {noformat}
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> logviewerservice-test ---
> [INFO] Surefire report directory:
> C:\StorageSpace\Projects\clj_project\logviewerservice-master\logviewerservice-test\target\surefire-reports
> ---
> T E S T S
> ---
> Das System kann den angegebenen Pfad nicht finden.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
> project logviewerservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> {noformat}
> The "Das System kann den angegebenen Pfad nicht finden." means, that given
> system path cannot be found.
> 1. Why mvn uses console language and not English?
> 2. Error message does not state which path cannot be found, so it makes
> impossible to solve the problem, as testing uses many different paths.
> 3. Everything happend before even target/surefire-reports directory is
> created.
> Can you help with that issue?
> The configuration is simple:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> {code}
> What is ofcourse interesting, why v. 2.19.1 appears to be v. 2.15 in build.
> Errors and exceptions are below:
> {noformat}
> [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
> surefire-api-2.15.jar test-classes classes
> ... (bunch of jars)
> surefire-testng-utils-2.15.jar surefire-grouper-2.15.jar
> surefire-testng-2.15.jar common-java5-2.15.jar
> Forking command line: cmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> Das System kann den angegebenen Pfad nicht finden.
> [ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test)
> on project myservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\suref
[jira] [Comment Edited] (SUREFIRE-1368) Not very informative fatal exit from testing - missing quotation in generated execution command
[
https://issues.apache.org/jira/browse/SUREFIRE-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989493#comment-15989493
]
Tibor Digana edited comment on SUREFIRE-1368 at 4/28/17 9:44 PM:
-
[~habdank]
It is always difficult with integration tools. Every change in POM and CI
should be verified.
Can you tell me if version {{2.20}} printed another error?
Do you still see the old version {{2.15}}?
[DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
I plan to make some changes which includes printing error message and not the
stack trace, unless you enable it via {{mvn -e}}.
This error happened before forked JVM started. The command is in console and
the jdk path as system property was not defined
[ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
was (Author: tibor17):
[~habdank]
It is always difficult with integration tools. Every change in POM and CI
should be verified.
Can you tell me if version {{2.20}} printed another error?
Do you still see the old version {{2.15}}?
>> [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
I plan to make some changes which includes printing error message and not the
stack trace, unless you enable it via {{mvn -e}}.
This error happened before forked JVM started. The command is in console and
the jdk path as system property was not defined
>>[ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
> Not very informative fatal exit from testing - missing quotation in generated
> execution command
> ---
>
> Key: SUREFIRE-1368
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1368
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.19.1
> Environment: Windows 10
>Reporter: Seweryn Habdank-Wojewodzki
>Assignee: Tibor Digana
>
> Dears,
> I am starting build {{mvn -X -e clean install}} which includes test written
> using TestNG framework v. 6.8.8.
> There comes following information:
> {noformat}
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> logviewerservice-test ---
> [INFO] Surefire report directory:
> C:\StorageSpace\Projects\clj_project\logviewerservice-master\logviewerservice-test\target\surefire-reports
> ---
> T E S T S
> ---
> Das System kann den angegebenen Pfad nicht finden.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
> project logviewerservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> {noformat}
> The "Das System kann den angegebenen Pfad nicht finden." means, that given
> system path cannot be found.
> 1. Why mvn uses console language and not English?
> 2. Error message does not state which path cannot be found, so it makes
> impossible to solve the problem, as testing uses many different paths.
> 3. Everything happend before even target/surefire-reports directory is
> created.
> Can you help with that issue?
> The configuration is simple:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> {code}
> What is ofcourse interesting, why v. 2.19.1 appears to be v. 2.15 in build.
> Errors and exceptions are below:
> {noformat}
> [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
> surefire-api-2.15.jar test-classes classes
> ... (bunch of jars)
> surefire-testng-utils-2.15.jar surefire-grouper-2.15.jar
> surefire-testng-2.15.jar common-java5-2.15.jar
> Forking command line: cmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> Das System kann den angegebenen Pfad nicht finden.
> [ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal
[jira] [Comment Edited] (SUREFIRE-1368) Not very informative fatal exit from testing - missing quotation in generated execution command
[
https://issues.apache.org/jira/browse/SUREFIRE-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989493#comment-15989493
]
Tibor Digana edited comment on SUREFIRE-1368 at 4/28/17 9:44 PM:
-
[~habdank]
It is always difficult with integration tools. Every change in POM and CI
should be verified.
Can you tell me if version {{2.20}} printed another error?
Do you still see the old version {{2.15}}?
>> [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
I plan to make some changes which includes printing error message and not the
stack trace, unless you enable it via {{mvn -e}}.
This error happened before forked JVM started. The command is in console and
the jdk path as system property was not defined
>>[ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
was (Author: tibor17):
[~habdank]
It is always difficult with integration tools. Every change in POM and CI
should be verified.
Can you tell me if version {{2.20}} printed another error?
Do you still see the old version {{2.15}}?
{[ [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar}}
I plan to make some changes which includes printing error message and not the
stack trace, unless you enable it via {{mvn -e}}.
This error happened before forked JVM started. The command is in console and
the jdk path as system property was not defined {{ [ERROR] Command wascmd.exe
/X /C "${jdk180.path}\bin\java}}
> Not very informative fatal exit from testing - missing quotation in generated
> execution command
> ---
>
> Key: SUREFIRE-1368
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1368
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.19.1
> Environment: Windows 10
>Reporter: Seweryn Habdank-Wojewodzki
>Assignee: Tibor Digana
>
> Dears,
> I am starting build {{mvn -X -e clean install}} which includes test written
> using TestNG framework v. 6.8.8.
> There comes following information:
> {noformat}
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> logviewerservice-test ---
> [INFO] Surefire report directory:
> C:\StorageSpace\Projects\clj_project\logviewerservice-master\logviewerservice-test\target\surefire-reports
> ---
> T E S T S
> ---
> Das System kann den angegebenen Pfad nicht finden.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
> project logviewerservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> {noformat}
> The "Das System kann den angegebenen Pfad nicht finden." means, that given
> system path cannot be found.
> 1. Why mvn uses console language and not English?
> 2. Error message does not state which path cannot be found, so it makes
> impossible to solve the problem, as testing uses many different paths.
> 3. Everything happend before even target/surefire-reports directory is
> created.
> Can you help with that issue?
> The configuration is simple:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> {code}
> What is ofcourse interesting, why v. 2.19.1 appears to be v. 2.15 in build.
> Errors and exceptions are below:
> {noformat}
> [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
> surefire-api-2.15.jar test-classes classes
> ... (bunch of jars)
> surefire-testng-utils-2.15.jar surefire-grouper-2.15.jar
> surefire-testng-2.15.jar common-java5-2.15.jar
> Forking command line: cmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> Das System kann den angegebenen Pfad nicht finden.
> [ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to exec
[jira] [Updated] (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:all-tabpanel
]
Tibor Digana updated SUREFIRE-1264:
---
Fix Version/s: 2.20.1
> 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
>
>
> 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.3.15#6346)
[jira] [Closed] (SUREFIRE-1263) No class name in log when running tests in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1263.
--
Resolution: Duplicate
> No class name in log when running tests in parallel with parameterized tests
>
>
> Key: SUREFIRE-1263
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1263
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
>
> Hello,
> Using surefire and Junit, the class names are not displayed in the output log
> when the tests are run in parallel with parameterized tests.
> According to this [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1], in
> parallel mode:
> {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
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 7.799 s
> [INFO] Finished at: 2016-07-27T15:03:37+02:00
> [INFO] Final Memory: 18M/213M
> [INFO]
>
> {noformat}
> Without parallel mode (we have the 'Running #classname#' in the output):
> {noformat}
> ---
> T E S T S
> ---
> Running com.appnexus.viewability.core.surefireJunitTests.ATest
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => 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[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.085 sec -
> in com.appnexus.viewability.core.surefireJunitTests.ATest
> Running com.appnexus.viewability.core.surefireJunitTests.BTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec -
> in com.appnexus.viewability.core.surefireJunitTests.BTest
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> It would be great to have the classname displayed when running tests in
> parallel.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1366) mvn javadoc:javadoc fails on Javadoc syntax with JDK 1.8
[ https://issues.apache.org/jira/browse/SUREFIRE-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1366. -- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=b54e33e68e9c3e13f8fca4b66dbb5c89a0a30715 > mvn javadoc:javadoc fails on Javadoc syntax with JDK 1.8 > > > Key: SUREFIRE-1366 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1366 > Project: Maven Surefire > Issue Type: Task >Reporter: Tibor Digana >Assignee: Tibor Digana > Labels: documentation, javadoc > Fix For: 2.20.1 > > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:javadoc (default-cli) on > project surefire-logger-api: An error has occurred in JavaDocs report > generation: > [ERROR] Exit code: 1 - ConsoleLogger.java:24: error: self-closing element not > allowed > [ERROR] * > [ERROR]^ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (SUREFIRE-1369) No way to output ANSI colors when running under Surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1369:
--
Assignee: Tibor Digana
> No way to output ANSI colors when running under Surefire
>
>
> Key: SUREFIRE-1369
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1369
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows 10 64-bit, 10.0.14393
>Reporter: Gili
>Assignee: Tibor Digana
>
> I invoke the following native code from inside a unit test:
> {{GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &sbi)}}
> It fails with {{GetLastError() == ERROR_INVALID_HANDLE}} indicating that
> stdout has been redirected.
> I am blocked by the fact that it isn't possible to use ANSI colors under
> Windows when stdout has been redirected. I tried configuring Surefire with:
> {code}
> 0
> false
> false
> false
> {code}
> but stdout is still getting redirected. Is it possible to configure Surefire
> to use the default stdout (connected to a terminal) without redirection?
> Expected behavior: Surefire shouldn't fork the JVM or redirect stdout when
> {{forkCount}} is zero and {{useFile}} is false.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1369) No way to output ANSI colors when running under Surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1369.
--
Resolution: Unresolved
Redirecting stream and forking has nothing to do with ANSI colors.
If you have native problem, report a bug in
https://issues.apache.org/jira/browse/MNG
> No way to output ANSI colors when running under Surefire
>
>
> Key: SUREFIRE-1369
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1369
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows 10 64-bit, 10.0.14393
>Reporter: Gili
>Assignee: Tibor Digana
>
> I invoke the following native code from inside a unit test:
> {{GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &sbi)}}
> It fails with {{GetLastError() == ERROR_INVALID_HANDLE}} indicating that
> stdout has been redirected.
> I am blocked by the fact that it isn't possible to use ANSI colors under
> Windows when stdout has been redirected. I tried configuring Surefire with:
> {code}
> 0
> false
> false
> false
> {code}
> but stdout is still getting redirected. Is it possible to configure Surefire
> to use the default stdout (connected to a terminal) without redirection?
> Expected behavior: Surefire shouldn't fork the JVM or redirect stdout when
> {{forkCount}} is zero and {{useFile}} is false.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[ https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15993992#comment-15993992 ] Tibor Digana commented on SUREFIRE-1265: [~eolivelli] Would you post a project to reproduce this issue? > reuseForks=false fails on jdk-9-ea builds > - > > Key: SUREFIRE-1265 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1265 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Michael Musgrove >Assignee: Tibor Digana > Labels: jigsaw > Fix For: 2.20.1 > > Attachments: j9test.tar > > > When I run any surefire test (with reuseForks=false) that uses java.sql > classes on recent jdk-9 ea builds it fails with: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on > project maven-surefire-plugin-example: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: > java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException > -> [Help 1] > If I run it with reuseForks=true it works fine. > This problem was introduced in jdk build 9-ea+122 > (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw > team addressed: > d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1369) No way to output ANSI colors when running under Surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994303#comment-15994303
]
Tibor Digana commented on SUREFIRE-1369:
We call {{System.setOut(...)}} in Java.
Is this what you call {{"redirected"}}?
We must do this in order to associate std/out/err with test method.
We do this around {{Provider}} and the provider itself decides whether the logs
go to console or to file {{target/surefire-reports/my.class-output.txt}}.
Is there any segmentation fault or an exception?
ANSI colors are under the control of Maven.
Here Surefire is only using high-level internal API to utilize low-level API
implemented in Maven.
Forked JVM does not have chance to use ANSI colors.
> No way to output ANSI colors when running under Surefire
>
>
> Key: SUREFIRE-1369
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1369
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows 10 64-bit, 10.0.14393
>Reporter: Gili
>Assignee: Tibor Digana
>
> I invoke the following native code from inside a unit test:
> {{GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &sbi)}}
> It fails with {{GetLastError() == ERROR_INVALID_HANDLE}} indicating that
> stdout has been redirected.
> I am blocked by the fact that it isn't possible to use ANSI colors under
> Windows when stdout has been redirected. I tried configuring Surefire with:
> {code}
> 0
> false
> false
> false
> {code}
> but stdout is still getting redirected. Is it possible to configure Surefire
> to use the default stdout (connected to a terminal) without redirection?
> Expected behavior: Surefire shouldn't fork the JVM or redirect stdout when
> {{forkCount}} is zero and {{useFile}} is false.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1369) No way to output ANSI colors when running under Surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994304#comment-15994304
]
Tibor Digana commented on SUREFIRE-1369:
One more question, why you are interested in JNDI and such things
{{GetStdHandle}}?
Is it your interest or commercial test?
> No way to output ANSI colors when running under Surefire
>
>
> Key: SUREFIRE-1369
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1369
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows 10 64-bit, 10.0.14393
>Reporter: Gili
>Assignee: Tibor Digana
>
> I invoke the following native code from inside a unit test:
> {{GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &sbi)}}
> It fails with {{GetLastError() == ERROR_INVALID_HANDLE}} indicating that
> stdout has been redirected.
> I am blocked by the fact that it isn't possible to use ANSI colors under
> Windows when stdout has been redirected. I tried configuring Surefire with:
> {code}
> 0
> false
> false
> false
> {code}
> but stdout is still getting redirected. Is it possible to configure Surefire
> to use the default stdout (connected to a terminal) without redirection?
> Expected behavior: Surefire shouldn't fork the JVM or redirect stdout when
> {{forkCount}} is zero and {{useFile}} is false.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[ https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994390#comment-15994390 ] Tibor Digana commented on SUREFIRE-1265: [~eolivelli] I committed a change yesterday. There should not be such limitation in enforcer anymore. Pls try again. > reuseForks=false fails on jdk-9-ea builds > - > > Key: SUREFIRE-1265 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1265 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Michael Musgrove >Assignee: Tibor Digana > Labels: jigsaw > Fix For: 2.20.1 > > Attachments: j9test.tar, Java9Example.zip > > > When I run any surefire test (with reuseForks=false) that uses java.sql > classes on recent jdk-9 ea builds it fails with: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on > project maven-surefire-plugin-example: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: > java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException > -> [Help 1] > If I run it with reuseForks=true it works fine. > This problem was introduced in jdk build 9-ea+122 > (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw > team addressed: > d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[ https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994480#comment-15994480 ] Tibor Digana commented on SUREFIRE-1265: [~eolivelli] This is caused by cxf plugin. So this is not the way to go. We have to setup JDK in JAVA_HOME for the particular IT test with JDK 9 via toolchain and run the IT in fork mode mean not embedded mode. Nevertheless you must build the project with JDK 8 and run the example project with JDK 9. > reuseForks=false fails on jdk-9-ea builds > - > > Key: SUREFIRE-1265 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1265 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Michael Musgrove >Assignee: Tibor Digana > Labels: jigsaw > Fix For: 2.20.1 > > Attachments: j9test.tar, Java9Example.zip > > > When I run any surefire test (with reuseForks=false) that uses java.sql > classes on recent jdk-9 ea builds it fails with: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on > project maven-surefire-plugin-example: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: > java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException > -> [Help 1] > If I run it with reuseForks=true it works fine. > This problem was introduced in jdk build 9-ea+122 > (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw > team addressed: > d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[ https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994534#comment-15994534 ] Tibor Digana commented on SUREFIRE-1265: Try to copy it to another directory on your file system and run it as a regular project. > reuseForks=false fails on jdk-9-ea builds > - > > Key: SUREFIRE-1265 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1265 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Michael Musgrove >Assignee: Tibor Digana > Labels: jigsaw > Fix For: 2.20.1 > > Attachments: j9test.tar, Java9Example.zip > > > When I run any surefire test (with reuseForks=false) that uses java.sql > classes on recent jdk-9 ea builds it fails with: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on > project maven-surefire-plugin-example: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: > java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException > -> [Help 1] > If I run it with reuseForks=true it works fine. > This problem was introduced in jdk build 9-ea+122 > (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw > team addressed: > d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[
https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994545#comment-15994545
]
Tibor Digana commented on SUREFIRE-1265:
[~rfscholte]
Should be put {{module-info.class}} in to the jar file or artifact which uses
{{IsolatedClassLoader}}?
Unfortunately this would be {{surefire-booter}}.
The ideal situation would be to have it in plugin's jar only and export all
modules in {{module-info.java}}:
module surefire.xyz {
java.activation, java.xml.bind, java.xml.ws,jdk.xml.bind
}
Should it be imported, or optional?
The whole problem is that isloated CL is used in plugin and ClassLoader does
not have any API call to extend the PlatformClassLoader with all JDK modules.
These modules would be nice to have as optional, means if the classes (tests)
in CL need to load them on the fly.
What can we do about this?
> reuseForks=false fails on jdk-9-ea builds
> -
>
> Key: SUREFIRE-1265
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1265
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Musgrove
>Assignee: Tibor Digana
> Labels: jigsaw
> Fix For: 2.20.1
>
> Attachments: j9test.tar, Java9Example.zip
>
>
> When I run any surefire test (with reuseForks=false) that uses java.sql
> classes on recent jdk-9 ea builds it fails with:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project maven-surefire-plugin-example: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed:
> java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException
> -> [Help 1]
> If I run it with reuseForks=true it works fine.
> This problem was introduced in jdk build 9-ea+122
> (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw
> team addressed:
> d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[
https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994545#comment-15994545
]
Tibor Digana edited comment on SUREFIRE-1265 at 5/3/17 9:29 AM:
[~rfscholte]
Should we put {{module-info.class}} in to the jar file or artifact which uses
{{IsolatedClassLoader}}?
Unfortunately this would be {{surefire-booter}}.
The ideal situation would be to have it in plugin's jar only and export all
modules in {{module-info.java}}:
module surefire.xyz {
java.activation, java.xml.bind, java.xml.ws,jdk.xml.bind
}
Should it be imported, or optional?
The whole problem is that isloated CL is used in plugin and ClassLoader does
not have any API call to extend the PlatformClassLoader with all JDK modules.
These modules would be nice to have as optional, means if the classes (tests)
in CL need to load them on the fly.
What can we do about this?
was (Author: tibor17):
[~rfscholte]
Should be put {{module-info.class}} in to the jar file or artifact which uses
{{IsolatedClassLoader}}?
Unfortunately this would be {{surefire-booter}}.
The ideal situation would be to have it in plugin's jar only and export all
modules in {{module-info.java}}:
module surefire.xyz {
java.activation, java.xml.bind, java.xml.ws,jdk.xml.bind
}
Should it be imported, or optional?
The whole problem is that isloated CL is used in plugin and ClassLoader does
not have any API call to extend the PlatformClassLoader with all JDK modules.
These modules would be nice to have as optional, means if the classes (tests)
in CL need to load them on the fly.
What can we do about this?
> reuseForks=false fails on jdk-9-ea builds
> -
>
> Key: SUREFIRE-1265
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1265
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Musgrove
>Assignee: Tibor Digana
> Labels: jigsaw
> Fix For: 2.20.1
>
> Attachments: j9test.tar, Java9Example.zip
>
>
> When I run any surefire test (with reuseForks=false) that uses java.sql
> classes on recent jdk-9 ea builds it fails with:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project maven-surefire-plugin-example: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed:
> java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException
> -> [Help 1]
> If I run it with reuseForks=true it works fine.
> This problem was introduced in jdk build 9-ea+122
> (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw
> team addressed:
> d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
