[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=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] [Closed] (SUREFIRE-2082) Huge test sets may open too many files
[
https://issues.apache.org/jira/browse/SUREFIRE-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-2082.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=d51e7c958a4f93876fafd23d12db0e1c686ec10a
> Huge test sets may open too many files
> --
>
> Key: SUREFIRE-2082
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2082
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Markus Spann
>Assignee: Tibor Digana
>Priority: Major
> Labels: patch, performance, pull-request-available
> Fix For: 3.0.0-M8
>
>
> Test sets with a very large number of tests (such as a JUnit
> {{ParameterizedTest}} with a large number of test inputs) cause surefire to
> open a file for _stdout_ and another file for _stderr_ as soon as a test
> method prints to either of these output streams.
> Surefire captures _stdout_ and _stderr_ in temporary files.
> These file handles are kept until the very end of the test set
> ({{{}TestSetRunListener.testSetCompleted{}}}) which may cause the limit of
> open files to be reached on a system, resulting in test errors
> ({{{}java.nio.file.FileSystemException{}}}, too many open files).
> This behavior may have been introduced with the performance improvements of
> SUREFIRE-1845.
> To reproduce, set the maximum allowed open files to a value lower than test
> iterations in a test class:
> {{ulimit -n }}
> where {{limit}} is the maximum number of open files for a user (Linux).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2082) Huge test sets may open too many files
[
https://issues.apache.org/jira/browse/SUREFIRE-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2082:
---
Fix Version/s: 3.0.0-M8
> Huge test sets may open too many files
> --
>
> Key: SUREFIRE-2082
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2082
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Markus Spann
>Assignee: Tibor Digana
>Priority: Major
> Labels: patch, performance, pull-request-available
> Fix For: 3.0.0-M8
>
>
> Test sets with a very large number of tests (such as a JUnit
> {{ParameterizedTest}} with a large number of test inputs) cause surefire to
> open a file for _stdout_ and another file for _stderr_ as soon as a test
> method prints to either of these output streams.
> Surefire captures _stdout_ and _stderr_ in temporary files.
> These file handles are kept until the very end of the test set
> ({{{}TestSetRunListener.testSetCompleted{}}}) which may cause the limit of
> open files to be reached on a system, resulting in test errors
> ({{{}java.nio.file.FileSystemException{}}}, too many open files).
> This behavior may have been introduced with the performance improvements of
> SUREFIRE-1845.
> To reproduce, set the maximum allowed open files to a value lower than test
> iterations in a test class:
> {{ulimit -n }}
> where {{limit}} is the maximum number of open files for a user (Linux).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (SUREFIRE-2082) Huge test sets may open too many files
[
https://issues.apache.org/jira/browse/SUREFIRE-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-2082:
--
Assignee: Tibor Digana
> Huge test sets may open too many files
> --
>
> Key: SUREFIRE-2082
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2082
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Markus Spann
>Assignee: Tibor Digana
>Priority: Major
> Labels: patch, performance, pull-request-available
>
> Test sets with a very large number of tests (such as a JUnit
> {{ParameterizedTest}} with a large number of test inputs) cause surefire to
> open a file for _stdout_ and another file for _stderr_ as soon as a test
> method prints to either of these output streams.
> Surefire captures _stdout_ and _stderr_ in temporary files.
> These file handles are kept until the very end of the test set
> ({{{}TestSetRunListener.testSetCompleted{}}}) which may cause the limit of
> open files to be reached on a system, resulting in test errors
> ({{{}java.nio.file.FileSystemException{}}}, too many open files).
> This behavior may have been introduced with the performance improvements of
> SUREFIRE-1845.
> To reproduce, set the maximum allowed open files to a value lower than test
> iterations in a test class:
> {{ulimit -n }}
> where {{limit}} is the maximum number of open files for a user (Linux).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (SUREFIRE-2076) BufferOverflowException when encoding message with null runMode
[
https://issues.apache.org/jira/browse/SUREFIRE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-2076.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=71f871751e3395e9d1646a34aa3433039fbfab2a
> BufferOverflowException when encoding message with null runMode
> ---
>
> Key: SUREFIRE-2076
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2076
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Zoltan Meze
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> Per
> [#issuecomment-1099231382|https://github.com/apache/maven-surefire/pull/518#issuecomment-1099231382],
>
> [#issuecomment-1099706229|https://github.com/apache/maven-surefire/pull/518#issuecomment-1099706229],
>
> [#pullrequestreview-951134938|https://github.com/apache/maven-surefire/pull/518#pullrequestreview-951134938]
> and
> [#issuecomment-1108371215|https://github.com/apache/maven-surefire/pull/518#issuecomment-1108371215]
> RunMode can be null causing BufferOverflowException when encoding message.
> Related to similar issue with null testIds:
> [SUREFIRE-2056|https://issues.apache.org/jira/browse/SUREFIRE-2056]
> [*AbstractStreamEncoder#encodeHeader*|https://github.com/apache/maven-surefire/blob/959c1e9cabb8d06c72f5ebd7eb6e56e9987eccf8/surefire-api/src/main/java/org/apache/maven/surefire/api/stream/AbstractStreamEncoder.java#L86]
> stores runMode in at least 3 bytes:
> * 1-byte length
> * 1-byte delimiter
> * length-bytes runMode
> * 1-byte delimiter
> In case of null runMode the encoded part becomes *0::* (exactly 3 bytes
> length)
> The issue is that
> [*AbstractStreamEncoder#estimateBufferLength*|https://github.com/apache/maven-surefire/blob/959c1e9cabb8d06c72f5ebd7eb6e56e9987eccf8/surefire-api/src/main/java/org/apache/maven/surefire/api/stream/AbstractStreamEncoder.java#L184]
> is not expecting/couting any bytes for runMode part in case of null runMode.
> This results in in BufferOverflowException becase the byte size of the
> message is underestimated.
> Exception thrown:
> {code:java}
> java.nio.BufferOverflowException
> at java.nio.Buffer.nextPutIndex(Buffer.java:547)
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:172)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
> at
> org.apache.maven.surefire.common.junit4.JUnit4RunListener.writeTestOutput(JUnit4RunListener.java:235)
> at
> org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2076) BufferOverflowException when encoding message with null runMode
[
https://issues.apache.org/jira/browse/SUREFIRE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2076:
---
Fix Version/s: 3.0.0-M7
> BufferOverflowException when encoding message with null runMode
> ---
>
> Key: SUREFIRE-2076
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2076
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Zoltan Meze
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> Per
> [#issuecomment-1099231382|https://github.com/apache/maven-surefire/pull/518#issuecomment-1099231382],
>
> [#issuecomment-1099706229|https://github.com/apache/maven-surefire/pull/518#issuecomment-1099706229],
>
> [#pullrequestreview-951134938|https://github.com/apache/maven-surefire/pull/518#pullrequestreview-951134938]
> and
> [#issuecomment-1108371215|https://github.com/apache/maven-surefire/pull/518#issuecomment-1108371215]
> RunMode can be null causing BufferOverflowException when encoding message.
> Related to similar issue with null testIds:
> [SUREFIRE-2056|https://issues.apache.org/jira/browse/SUREFIRE-2056]
> [*AbstractStreamEncoder#encodeHeader*|https://github.com/apache/maven-surefire/blob/959c1e9cabb8d06c72f5ebd7eb6e56e9987eccf8/surefire-api/src/main/java/org/apache/maven/surefire/api/stream/AbstractStreamEncoder.java#L86]
> stores runMode in at least 3 bytes:
> * 1-byte length
> * 1-byte delimiter
> * length-bytes runMode
> * 1-byte delimiter
> In case of null runMode the encoded part becomes *0::* (exactly 3 bytes
> length)
> The issue is that
> [*AbstractStreamEncoder#estimateBufferLength*|https://github.com/apache/maven-surefire/blob/959c1e9cabb8d06c72f5ebd7eb6e56e9987eccf8/surefire-api/src/main/java/org/apache/maven/surefire/api/stream/AbstractStreamEncoder.java#L184]
> is not expecting/couting any bytes for runMode part in case of null runMode.
> This results in in BufferOverflowException becase the byte size of the
> message is underestimated.
> Exception thrown:
> {code:java}
> java.nio.BufferOverflowException
> at java.nio.Buffer.nextPutIndex(Buffer.java:547)
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:172)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
> at
> org.apache.maven.surefire.common.junit4.JUnit4RunListener.writeTestOutput(JUnit4RunListener.java:235)
> at
> org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (SUREFIRE-2076) BufferOverflowException when encoding message with null runMode
[
https://issues.apache.org/jira/browse/SUREFIRE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-2076:
--
Assignee: Tibor Digana
> BufferOverflowException when encoding message with null runMode
> ---
>
> Key: SUREFIRE-2076
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2076
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Zoltan Meze
>Assignee: Tibor Digana
>Priority: Major
>
> Per
> [#issuecomment-1099231382|https://github.com/apache/maven-surefire/pull/518#issuecomment-1099231382],
>
> [#issuecomment-1099706229|https://github.com/apache/maven-surefire/pull/518#issuecomment-1099706229],
>
> [#pullrequestreview-951134938|https://github.com/apache/maven-surefire/pull/518#pullrequestreview-951134938]
> and
> [#issuecomment-1108371215|https://github.com/apache/maven-surefire/pull/518#issuecomment-1108371215]
> RunMode can be null causing BufferOverflowException when encoding message.
> Related to similar issue with null testIds:
> [SUREFIRE-2056|https://issues.apache.org/jira/browse/SUREFIRE-2056]
> [*AbstractStreamEncoder#encodeHeader*|https://github.com/apache/maven-surefire/blob/959c1e9cabb8d06c72f5ebd7eb6e56e9987eccf8/surefire-api/src/main/java/org/apache/maven/surefire/api/stream/AbstractStreamEncoder.java#L86]
> stores runMode in at least 3 bytes:
> * 1-byte length
> * 1-byte delimiter
> * length-bytes runMode
> * 1-byte delimiter
> In case of null runMode the encoded part becomes *0::* (exactly 3 bytes
> length)
> The issue is that
> [*AbstractStreamEncoder#estimateBufferLength*|https://github.com/apache/maven-surefire/blob/959c1e9cabb8d06c72f5ebd7eb6e56e9987eccf8/surefire-api/src/main/java/org/apache/maven/surefire/api/stream/AbstractStreamEncoder.java#L184]
> is not expecting/couting any bytes for runMode part in case of null runMode.
> This results in in BufferOverflowException becase the byte size of the
> message is underestimated.
> Exception thrown:
> {code:java}
> java.nio.BufferOverflowException
> at java.nio.Buffer.nextPutIndex(Buffer.java:547)
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:172)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
> at
> org.apache.maven.surefire.common.junit4.JUnit4RunListener.writeTestOutput(JUnit4RunListener.java:235)
> at
> org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-2058.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=754dd9c45315ff9de20a83c2a0f11af3112159ec
> Corrupted STDOUT by directly writing to native stream in forked JVM 1 with
> UTF-8 console logging
>
>
> Key: SUREFIRE-2058
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2058
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Zoltan Meze
>Assignee: Tibor Digana
>Priority: Blocker
> Fix For: 3.0.0-M7
>
>
> With 3.0.0-M6 surefire and slf4j + logback, most test runs end up with:
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1. {code}
> This only affects *3.0.0-M6* (3.0.0-M5 version is working fine in test
> project).
>
> After some digging, there are two different scenarios (most likely caused by
> the same issue):
> * 2-byte character at position 1023 (or N * 1024 - 1) in log message is
> causing the following warning
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1.
> {code}
> To reproduce this issue logback (with slf4j) should be used.
> Not able to reproduce with System.out.println.
> * 4-byte character at position 1023 (or N * 1024 - 1) in log message.
> Can be reproduced with System.out.println (logback not required in this case).
> This blocks surefire entirely at (from jstack):
> {code:java}
> "fork-1-event-thread" #30 daemon prio=5 os_prio=0 cpu=32350.09ms
> elapsed=32.94s tid=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.decodeString(AbstractStreamDecoder.java:350)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:322)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:196)
> at
> org.apache.maven.surefire.stream.EventDecoder.decode(EventDecoder.java:176)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:73)
> {code}
>
> Project with reproducible tests (for both scenarios, more in README):
> [https://github.com/zoltanmeze/surefire-corrupted-channel]
>
> One workaround on M6 for now is to use different charset (instead of default
> UTF-8) or limit message size.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2058:
---
Fix Version/s: 3.0.0-M7
> Corrupted STDOUT by directly writing to native stream in forked JVM 1 with
> UTF-8 console logging
>
>
> Key: SUREFIRE-2058
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2058
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Zoltan Meze
>Priority: Blocker
> Fix For: 3.0.0-M7
>
>
> With 3.0.0-M6 surefire and slf4j + logback, most test runs end up with:
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1. {code}
> This only affects *3.0.0-M6* (3.0.0-M5 version is working fine in test
> project).
>
> After some digging, there are two different scenarios (most likely caused by
> the same issue):
> * 2-byte character at position 1023 (or N * 1024 - 1) in log message is
> causing the following warning
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1.
> {code}
> To reproduce this issue logback (with slf4j) should be used.
> Not able to reproduce with System.out.println.
> * 4-byte character at position 1023 (or N * 1024 - 1) in log message.
> Can be reproduced with System.out.println (logback not required in this case).
> This blocks surefire entirely at (from jstack):
> {code:java}
> "fork-1-event-thread" #30 daemon prio=5 os_prio=0 cpu=32350.09ms
> elapsed=32.94s tid=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.decodeString(AbstractStreamDecoder.java:350)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:322)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:196)
> at
> org.apache.maven.surefire.stream.EventDecoder.decode(EventDecoder.java:176)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:73)
> {code}
>
> Project with reproducible tests (for both scenarios, more in README):
> [https://github.com/zoltanmeze/surefire-corrupted-channel]
>
> One workaround on M6 for now is to use different charset (instead of default
> UTF-8) or limit message size.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-2058:
--
Assignee: Tibor Digana
> Corrupted STDOUT by directly writing to native stream in forked JVM 1 with
> UTF-8 console logging
>
>
> Key: SUREFIRE-2058
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2058
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Zoltan Meze
>Assignee: Tibor Digana
>Priority: Blocker
> Fix For: 3.0.0-M7
>
>
> With 3.0.0-M6 surefire and slf4j + logback, most test runs end up with:
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1. {code}
> This only affects *3.0.0-M6* (3.0.0-M5 version is working fine in test
> project).
>
> After some digging, there are two different scenarios (most likely caused by
> the same issue):
> * 2-byte character at position 1023 (or N * 1024 - 1) in log message is
> causing the following warning
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1.
> {code}
> To reproduce this issue logback (with slf4j) should be used.
> Not able to reproduce with System.out.println.
> * 4-byte character at position 1023 (or N * 1024 - 1) in log message.
> Can be reproduced with System.out.println (logback not required in this case).
> This blocks surefire entirely at (from jstack):
> {code:java}
> "fork-1-event-thread" #30 daemon prio=5 os_prio=0 cpu=32350.09ms
> elapsed=32.94s tid=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.decodeString(AbstractStreamDecoder.java:350)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:322)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:196)
> at
> org.apache.maven.surefire.stream.EventDecoder.decode(EventDecoder.java:176)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:73)
> {code}
>
> Project with reproducible tests (for both scenarios, more in README):
> [https://github.com/zoltanmeze/surefire-corrupted-channel]
>
> One workaround on M6 for now is to use different charset (instead of default
> UTF-8) or limit message size.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2063) Adding argLine with tab characters fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527609#comment-17527609
]
Tibor Digana commented on SUREFIRE-2063:
[~mthmulders]
The problem I see here is teh fact that we have already pushed this fix to
master and we closed this issue. We should not push more and more commits
within one Jira issue. So we should rephrase our needs, describe it why we need
it and do it properly in Jira and the code but I hope it would be the last one
regarding similar issue.
> Adding argLine with tab characters fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Assignee: Maarten Mulders
>Priority: Blocker
> Fix For: 3.0.0-M7
>
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2063) Adding argLine with tab characters fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527608#comment-17527608
]
Tibor Digana commented on SUREFIRE-2063:
[~mthmulders]
Basically, I don't mind due to I am not having this problem. I would prefer
some kind of backwards compatibility unless there is a strong reason to change
it.
> Adding argLine with tab characters fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Assignee: Maarten Mulders
>Priority: Blocker
> Fix For: 3.0.0-M7
>
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2064) Implementation of TestNG "parallel" option fails with default value
[
https://issues.apache.org/jira/browse/SUREFIRE-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2064:
---
Fix Version/s: 2.22.3
> Implementation of TestNG "parallel" option fails with default value
> ---
>
> Key: SUREFIRE-2064
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2064
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M6
>Reporter: Scott Babcock
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M7
>
>
> The latest release of Maven Surefire attempts to resolve an incompatibility
> with TestNG 7.4+, but the way the fix was implemented causes projects that
> don't specify parallel execution to fail:
> {code:java}
> [ERROR] There was an error in the forked process
> [ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
> supported )
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
> supported )
> {code}
> "none" is the default value that gets passed in if no [parallel] setting is
> specified. TestNG actually supports NONE as a valid value, along with TESTS
> and INSTANCES. There are two deprecated values as well (TRUE and FALSE),
> which cause TestNG to log a warning and translate to equivalent supported
> values (METHODS and NONE respectively).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (SUREFIRE-2064) Implementation of TestNG "parallel" option fails with default value
[
https://issues.apache.org/jira/browse/SUREFIRE-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-2064.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=cbf7df3564470e57af11c243356b93c74622befc
> Implementation of TestNG "parallel" option fails with default value
> ---
>
> Key: SUREFIRE-2064
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2064
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M6
>Reporter: Scott Babcock
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> The latest release of Maven Surefire attempts to resolve an incompatibility
> with TestNG 7.4+, but the way the fix was implemented causes projects that
> don't specify parallel execution to fail:
> {code:java}
> [ERROR] There was an error in the forked process
> [ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
> supported )
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
> supported )
> {code}
> "none" is the default value that gets passed in if no [parallel] setting is
> specified. TestNG actually supports NONE as a valid value, along with TESTS
> and INSTANCES. There are two deprecated values as well (TRUE and FALSE),
> which cause TestNG to log a warning and translate to equivalent supported
> values (METHODS and NONE respectively).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (SUREFIRE-2064) Implementation of TestNG "parallel" option fails with default value
[
https://issues.apache.org/jira/browse/SUREFIRE-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-2064:
--
Assignee: Tibor Digana
> Implementation of TestNG "parallel" option fails with default value
> ---
>
> Key: SUREFIRE-2064
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2064
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M6
>Reporter: Scott Babcock
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> The latest release of Maven Surefire attempts to resolve an incompatibility
> with TestNG 7.4+, but the way the fix was implemented causes projects that
> don't specify parallel execution to fail:
> {code:java}
> [ERROR] There was an error in the forked process
> [ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
> supported )
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
> supported )
> {code}
> "none" is the default value that gets passed in if no [parallel] setting is
> specified. TestNG actually supports NONE as a valid value, along with TESTS
> and INSTANCES. There are two deprecated values as well (TRUE and FALSE),
> which cause TestNG to log a warning and translate to equivalent supported
> values (METHODS and NONE respectively).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2064) Implementation of TestNG "parallel" option fails with default value
[
https://issues.apache.org/jira/browse/SUREFIRE-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2064:
---
Fix Version/s: 3.0.0-M7
> Implementation of TestNG "parallel" option fails with default value
> ---
>
> Key: SUREFIRE-2064
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2064
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M6
>Reporter: Scott Babcock
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> The latest release of Maven Surefire attempts to resolve an incompatibility
> with TestNG 7.4+, but the way the fix was implemented causes projects that
> don't specify parallel execution to fail:
> {code:java}
> [ERROR] There was an error in the forked process
> [ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
> supported )
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] Unsupported TestNG parallel setting: none ( only METHODS or CLASSES
> supported )
> {code}
> "none" is the default value that gets passed in if no [parallel] setting is
> specified. TestNG actually supports NONE as a valid value, along with TESTS
> and INSTANCES. There are two deprecated values as well (TRUE and FALSE),
> which cause TestNG to log a warning and translate to equivalent supported
> values (METHODS and NONE respectively).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2072) Surefire retains too much heap in some case, leading to OutOfMemory
[ https://issues.apache.org/jira/browse/SUREFIRE-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524325#comment-17524325 ] Tibor Digana commented on SUREFIRE-2072: [~mickael.istria] Regarding our code, TestSetRunListener appears in maven-surefire-common, and it dependent on Maven API which means that it must be part of the forked JVM, otherwise it breaks some project strengths. Haing it in the forked JVM may lead to these issues because the instance of TestSetRunListener would be one, I guess as in Eclipse Tycho, and the objects would be reclaimed after the method testSetCompleted() is finished. > Surefire retains too much heap in some case, leading to OutOfMemory > --- > > Key: SUREFIRE-2072 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2072 > Project: Maven Surefire > Issue Type: Bug >Reporter: Mickael Istria >Priority: Major > > Most likely since SuREFIRE-1845, every test execution can retain 64kB of RAM > (as cache). Which caching is welcome, this cannot scale with some big test > suites of several thousands of tests and cause OutOfMemoryError. > This is the case when running Eclipse JDT dom test suite, since > tycho-surefire-plugin started to adopt surefire 3.0.0.M6, as described in > https://github.com/eclipse/tycho/issues/879#issuecomment-1096454637 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523819#comment-17523819
]
Tibor Digana edited comment on SUREFIRE-2063 at 4/18/22 6:38 PM:
-
[~dsubel]
We have also our internal needs. Difficult to explain briefly. Unfortunatelly
non-Maven guys cannot see the release backlog, it's the Jira issue, therefore
we have published the roadmap on the Surefire site.
was (Author: tibor17):
[~dsubel]
We have also our internal needs. Difficult to explain in short. Unfortunatelly
non-Maven guys cannot see the release backlog, it's the Jira issue, therefore
we have published the roadmap on the Surefire site.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523819#comment-17523819
]
Tibor Digana edited comment on SUREFIRE-2063 at 4/18/22 6:36 PM:
-
[~dsubel]
We have also our internal needs. Difficult to explain in short. Unfortunatelly
non-Maven guys cannot see the release backlog, it's the Jira issue, therefore
we have published the roadmap on the Surefire site.
was (Author: tibor17):
[~dsubel]
We have also our internal needs. It is very difficult to explain.
Unfortunatelly non-Maven guys cannot see the release backlog, it's the Jira
issue, therefore we have published the roadmap on the Surefire site.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523819#comment-17523819
]
Tibor Digana commented on SUREFIRE-2063:
[~dsubel]
We have also our internal needs. It is very difficult to explain.
Unfortunatelly non-Maven guys cannot see the release backlog, it's the Jira
issue, therefore we have published the roadmap on the Surefire site.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523463#comment-17523463
]
Tibor Digana commented on SUREFIRE-2063:
[~dsubel] because we updated the version of {{maven-shared-utils}}. It contains
the CLI utility. These changes may happen in CLI.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523450#comment-17523450
]
Tibor Digana commented on SUREFIRE-2063:
According to [~mthmulders]' PR the only problem is with {{argLine}}, especially
the problem with removing the characters {{\n\t\r}} - \t missing.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2074) Junit 5 @Nested Tests executes when excluded
[
https://issues.apache.org/jira/browse/SUREFIRE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2074:
---
Fix Version/s: waiting-for-apache-feedback
> Junit 5 @Nested Tests executes when excluded
>
>
> Key: SUREFIRE-2074
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2074
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Henrik Josefsson
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> Test classes with the Junit 5 `@Nested` annotation is executed even when
> explicitly excluded with the `` tag.
> h2. Minimal reproducing example
> [https://github.com/Steinstark/surefire-issue] see the IssueTest.
> h2. Surefire configuration
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M6
>
>
> **/IssueTest$NestedTests
>
>
> {code}
> h2. Expected behavior
> The tests inside the `@Nested` excluded class is not run.
> h2. Actual behavior
> The tests inside the `@Nested` excluded class is run.
> h2. Additional info
> I believe the problem is caused by only setting the selectors based on the
> exact classes surefire is expected to run for the
> LauncherDiscoveryRequestBuilder in JunitPlatformProvider but as far as I can
> tell Junit will by default discover `@Nested` classes aswell from the
> selectors.
> The solution is probably to provide a filter in addition to the selector. Not
> sure if it is a good solution but locally I changed the newFilters method to
> always add the TestMethodFilter and it appear to have worked. Might be
> something worth looking further into at least.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2073) Test class filtering should be done in the particular fork JVM where the real test would run.
[
https://issues.apache.org/jira/browse/SUREFIRE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2073:
---
Fix Version/s: 3.0
> Test class filtering should be done in the particular fork JVM where the real
> test would run.
> -
>
> Key: SUREFIRE-2073
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2073
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Piotr Karwasz
>Priority: Major
> Fix For: 3.0
>
>
> On projects using toolchains submodules can be compiled with a different Java
> version than the main project. This can result in an
> {{UnsupportedClassVersionError}} if the class scan is performed by the main
> Maven JVM:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (test) on
> project log4j-api-java9: Execution test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed:
> java.lang.UnsupportedClassVersionError:
> org/apache/logging/log4j/util/java9/ProcessIdUtilTest has been compiled by a
> more recent version of the Java Runtime (class file version 53.0), this
> version of the Java Runtime only recognizes class file versions up to 52.0 ->
> [Help 1]{noformat}
> Therefore Surefire should probably fork a new instance to scan for test
> classes whenever {{forkCount}} is not zero.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2073) Test class filtering should be done in the particular fork JVM where the real test would run.
[
https://issues.apache.org/jira/browse/SUREFIRE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2073:
---
Summary: Test class filtering should be done in the particular fork JVM
where the real test would run. (was: Surefire should fork before class scan.
Test class filtering should be done in the particular fork JVM where the real
test would run.)
> Test class filtering should be done in the particular fork JVM where the real
> test would run.
> -
>
> Key: SUREFIRE-2073
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2073
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Piotr Karwasz
>Priority: Major
>
> On projects using toolchains submodules can be compiled with a different Java
> version than the main project. This can result in an
> {{UnsupportedClassVersionError}} if the class scan is performed by the main
> Maven JVM:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (test) on
> project log4j-api-java9: Execution test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed:
> java.lang.UnsupportedClassVersionError:
> org/apache/logging/log4j/util/java9/ProcessIdUtilTest has been compiled by a
> more recent version of the Java Runtime (class file version 53.0), this
> version of the Java Runtime only recognizes class file versions up to 52.0 ->
> [Help 1]{noformat}
> Therefore Surefire should probably fork a new instance to scan for test
> classes whenever {{forkCount}} is not zero.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2073) Surefire should fork before class scan. Test class filtering should be done in the particular fork JVM where the real test would run.
[
https://issues.apache.org/jira/browse/SUREFIRE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2073:
---
Summary: Surefire should fork before class scan. Test class filtering
should be done in the particular fork JVM where the real test would run. (was:
Surefire should fork before class scan)
> Surefire should fork before class scan. Test class filtering should be done
> in the particular fork JVM where the real test would run.
> -
>
> Key: SUREFIRE-2073
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2073
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Piotr Karwasz
>Priority: Major
>
> On projects using toolchains submodules can be compiled with a different Java
> version than the main project. This can result in an
> {{UnsupportedClassVersionError}} if the class scan is performed by the main
> Maven JVM:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (test) on
> project log4j-api-java9: Execution test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed:
> java.lang.UnsupportedClassVersionError:
> org/apache/logging/log4j/util/java9/ProcessIdUtilTest has been compiled by a
> more recent version of the Java Runtime (class file version 53.0), this
> version of the Java Runtime only recognizes class file versions up to 52.0 ->
> [Help 1]{noformat}
> Therefore Surefire should probably fork a new instance to scan for test
> classes whenever {{forkCount}} is not zero.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2073) Surefire should fork before class scan
[
https://issues.apache.org/jira/browse/SUREFIRE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522817#comment-17522817
]
Tibor Digana commented on SUREFIRE-2073:
SUREFIRE-2048 and SUREFIRE-2049 are a prereq for this change.
> Surefire should fork before class scan
> --
>
> Key: SUREFIRE-2073
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2073
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Piotr Karwasz
>Priority: Major
>
> On projects using toolchains submodules can be compiled with a different Java
> version than the main project. This can result in an
> {{UnsupportedClassVersionError}} if the class scan is performed by the main
> Maven JVM:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (test) on
> project log4j-api-java9: Execution test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed:
> java.lang.UnsupportedClassVersionError:
> org/apache/logging/log4j/util/java9/ProcessIdUtilTest has been compiled by a
> more recent version of the Java Runtime (class file version 53.0), this
> version of the Java Runtime only recognizes class file versions up to 52.0 ->
> [Help 1]{noformat}
> Therefore Surefire should probably fork a new instance to scan for test
> classes whenever {{forkCount}} is not zero.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (SUREFIRE-2057) JPMS Regression: requires static module not include anymore
[ https://issues.apache.org/jira/browse/SUREFIRE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-2057. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=541a65d6275dd5a5bb2a40be16716ebb2c637609 > JPMS Regression: requires static module not include anymore > --- > > Key: SUREFIRE-2057 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2057 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 3.0.0-M7 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2072) Surefire retains too much heap in some case, leading to OutOfMemory
[ https://issues.apache.org/jira/browse/SUREFIRE-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522541#comment-17522541 ] Tibor Digana commented on SUREFIRE-2072: > after each test; while the TestSetRunListener does grow greedily That's what I said as well. It grows because the Queue does not free the streams when not used by the logic. > Surefire retains too much heap in some case, leading to OutOfMemory > --- > > Key: SUREFIRE-2072 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2072 > Project: Maven Surefire > Issue Type: Bug >Reporter: Mickael Istria >Priority: Major > > Most likely since SuREFIRE-1845, every test execution can retain 64kB of RAM > (as cache). Which caching is welcome, this cannot scale with some big test > suites of several thousands of tests and cause OutOfMemoryError. > This is the case when running Eclipse JDT dom test suite, since > tycho-surefire-plugin started to adopt surefire 3.0.0.M6, as described in > https://github.com/eclipse/tycho/issues/879#issuecomment-1096454637 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-2072) Surefire retains too much heap in some case, leading to OutOfMemory
[
https://issues.apache.org/jira/browse/SUREFIRE-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522446#comment-17522446
]
Tibor Digana edited comment on SUREFIRE-2072 at 4/14/22 6:15 PM:
-
[~mickael.istria]
We can make the cache much smaller, e.g. 1024 bytes, but I think the real
problem is that we do not have a proper clean up of {{stdout}} and {{stderr}}
in {{TestSetRunListener.detailsForThis}} after the particular test class has
finished. Anyway, this class and {{StatelessXmlReporter}} will be reworked. We
have several problems with them.
The reason why it is 64KB:
Suppose you have {{forkMode=pertest}} and {{reuseForks=false}}. Each test class
runs in a separate fork.
The object of {{TestSetRunListener}} is not in fork. It is in Maven process.
You have 1000 test classes, each has one test method.
Suppose you have a super small project and each fork eats 10MB of native memory.
Altogether, all the forks would eat 1000 x 10MB = 10GB.
Let's count the additive memory consumption in the Maven process.
You have 1000 test classes and one cache, this means the object
{{TestSetRunListener}} would eat 1000 x 64KB = 64MB.
So the penalty is not on the side of the cache.
The effectivity of memory clean up is the issue, I would say.
was (Author: tibor17):
[~mickael.istria]
We can make the cache much smaller, e.g. 1024 bytes, but I think we do not have
a proper clean up of {{stdout}} and {{stderr}} in
{{TestSetRunListener.detailsForThis}} after the particular test class has
finished. Anyway, this class and {{StatelessXmlReporter}} will be reworked. We
have several problems with them.
The reason why it is 64KB:
Suppose you have {{forkMode=pertest}} and {{reuseForks=false}}. Each test class
runs in a separate fork.
The object of {{TestSetRunListener}} is not in fork. It is in Maven process.
You have 1000 test classes, each has one test method.
Suppose you have a super small project and each fork eats 10MB of native memory.
Altogether, all the forks would eat 1000 x 10MB = 10GB.
Let's count the additive memory consumption in the Maven process.
You have 1000 test classes and one cache, this means the object
{{TestSetRunListener}} would eat 1000 x 64KB = 64MB.
So the penalty is not on the side of the cache.
The effectivity of memory clean up is the issue, I would say.
> Surefire retains too much heap in some case, leading to OutOfMemory
> ---
>
> Key: SUREFIRE-2072
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2072
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Mickael Istria
>Priority: Major
>
> Most likely since SuREFIRE-1845, every test execution can retain 64kB of RAM
> (as cache). Which caching is welcome, this cannot scale with some big test
> suites of several thousands of tests and cause OutOfMemoryError.
> This is the case when running Eclipse JDT dom test suite, since
> tycho-surefire-plugin started to adopt surefire 3.0.0.M6, as described in
> https://github.com/eclipse/tycho/issues/879#issuecomment-1096454637
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2072) Surefire retains too much heap in some case, leading to OutOfMemory
[
https://issues.apache.org/jira/browse/SUREFIRE-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522446#comment-17522446
]
Tibor Digana commented on SUREFIRE-2072:
[~mickael.istria]
We can make the cache much smaller, e.g. 1024 bytes, but I think we do not have
a proper clean up of {{stdout}} and {{stderr}} in
{{TestSetRunListener.detailsForThis}} after the particular test class has
finished. Anyway, this class and {{StatelessXmlReporter}} will be reworked. We
have several problems with them.
The reason why it is 64KB:
Suppose you have {{forkMode=pertest}} and {{reuseForks=false}}. Each test class
runs in a separate fork.
The object of {{TestSetRunListener}} is not in fork. It is in Maven process.
You have 1000 test classes, each has one test method.
Suppose you have a super small project and each fork eats 10MB of native memory.
Altogether, all the forks would eat 1000 x 10MB = 10GB.
Let's count the additive memory consumption in the Maven process.
You have 1000 test classes and one cache, this means the object
{{TestSetRunListener}} would eat 1000 x 64KB = 64MB.
So the penalty is not on the side of the cache.
The effectivity of memory clean up is the issue, I would say.
> Surefire retains too much heap in some case, leading to OutOfMemory
> ---
>
> Key: SUREFIRE-2072
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2072
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Mickael Istria
>Priority: Major
>
> Most likely since SuREFIRE-1845, every test execution can retain 64kB of RAM
> (as cache). Which caching is welcome, this cannot scale with some big test
> suites of several thousands of tests and cause OutOfMemoryError.
> This is the case when running Eclipse JDT dom test suite, since
> tycho-surefire-plugin started to adopt surefire 3.0.0.M6, as described in
> https://github.com/eclipse/tycho/issues/879#issuecomment-1096454637
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2073) Surefire should fork before class scan
[
https://issues.apache.org/jira/browse/SUREFIRE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522358#comment-17522358
]
Tibor Digana commented on SUREFIRE-2073:
This is not a bug. It is such design.
Our plan is to change Provider interface and maybe we will have a chance to
filter the class already in the fork JVM. This is also our plan but it is not
easy.
> Surefire should fork before class scan
> --
>
> Key: SUREFIRE-2073
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2073
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Piotr Karwasz
>Priority: Major
>
> On projects using toolchains submodules can be compiled with a different Java
> version than the main project. This can result in an
> {{UnsupportedClassVersionError}} if the class scan is performed by the main
> Maven JVM:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (test) on
> project log4j-api-java9: Execution test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed:
> java.lang.UnsupportedClassVersionError:
> org/apache/logging/log4j/util/java9/ProcessIdUtilTest has been compiled by a
> more recent version of the Java Runtime (class file version 53.0), this
> version of the Java Runtime only recognizes class file versions up to 52.0 ->
> [Help 1]{noformat}
> Therefore Surefire should probably fork a new instance to scan for test
> classes whenever {{forkCount}} is not zero.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (SUREFIRE-2066) Wrong documentation "List of System properties to pass to the JUnit tests." of systemProperties and systemPropertyVariables
[
https://issues.apache.org/jira/browse/SUREFIRE-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-2066.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=f6be3e648938414b222b50907b1db2d6a3cc977b
> Wrong documentation "List of System properties to pass to the JUnit tests."
> of systemProperties and systemPropertyVariables
> ---
>
> Key: SUREFIRE-2066
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2066
> Project: Maven Surefire
> Issue Type: Improvement
> Components: documentation
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> The configuration parameters {{systemProperties}} and
> {{systemPropertyVariables}} have wrong JavaDoc:
> {noformat}
> List of System properties to pass to the JUnit tests.
> {noformat}
> The problem is with targeting "JUnit tests".
> Both parameters have general purpose.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SUREFIRE-2066) Wrong documentation "List of System properties to pass to the JUnit tests." of systemProperties and systemPropertyVariables
Tibor Digana created SUREFIRE-2066:
--
Summary: Wrong documentation "List of System properties to pass to
the JUnit tests." of systemProperties and systemPropertyVariables
Key: SUREFIRE-2066
URL: https://issues.apache.org/jira/browse/SUREFIRE-2066
Project: Maven Surefire
Issue Type: Improvement
Components: documentation
Reporter: Tibor Digana
Assignee: Tibor Digana
Fix For: 3.0.0-M7
The configuration parameters {{systemProperties}} and
{{systemPropertyVariables}} have wrong JavaDoc:
{noformat}
List of System properties to pass to the JUnit tests.
{noformat}
The problem is with targeting "JUnit tests".
Both parameters have general purpose.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-2061) BLOCKED in surefire-forkedjvm-stream-flusher
[
https://issues.apache.org/jira/browse/SUREFIRE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520019#comment-17520019
]
Tibor Digana edited comment on SUREFIRE-2061 at 4/9/22 8:17 PM:
Hey [~sjaranowski], pls try to find the dump in target/surefire-reports.
It would be some exception, I guess, NPE or something similar.
was (Author: tibor17):
Hey [~sjaranowski], pls try to find the dump in target/surefire-reports.
It would some exception, I guess, NPE or something similar.
> BLOCKED in surefire-forkedjvm-stream-flusher
>
>
> Key: SUREFIRE-2061
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2061
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Slawomir Jaranowski
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> From time to time test execution is hung up - wait forever ...
> Now I can't reproduce it, test rerun fix it.
> The stack is:
> {code}
> 2022-04-06 13:59:05
> Full thread dump OpenJDK 64-Bit Server VM (25.322-b00 mixed mode):
> "Attach Listener" #16 daemon prio=9 os_prio=31 tid=0x7fe48036a000
> nid=0x380b waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "surefire-forkedjvm-command-thread" #12 daemon prio=5 os_prio=31
> tid=0x7fe504a5c000 nid=0xa803 runnable [0x7db43000]
>java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:255)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0x0005c000ccb0> (a java.io.BufferedInputStream)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0x0005c000ccd8> (a java.io.BufferedInputStream)
> at
> org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleReadableChannel.read(AbstractNoninterruptibleReadableChannel.java:54)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.read(AbstractStreamDecoder.java:487)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.read(AbstractStreamDecoder.java:473)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readMessageType(AbstractStreamDecoder.java:118)
> at
> org.apache.maven.surefire.booter.stream.CommandDecoder.decode(CommandDecoder.java:87)
> at
> org.apache.maven.surefire.booter.spi.CommandChannelDecoder.decode(CommandChannelDecoder.java:67)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:345)
> at java.lang.Thread.run(Thread.java:750)
> "surefire-forkedjvm-stream-flusher" #10 daemon prio=5 os_prio=31
> tid=0x7fe500969000 nid=0xa903 waiting for monitor entry
> [0x7da4]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:117)
> - waiting to lock <0x0005c000d498> (a java.io.BufferedOutputStream)
> at
> org.apache.maven.surefire.api.util.internal.Channels$4.writeImpl(Channels.java:253)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:72)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:45)
> at
> org.apache.maven.surefire.booter.spi.AbstractMasterProcessChannelProcessorFactory$1.run(AbstractMasterProcessChannelProcessorFactory.java:65)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:750)
> "Service Thread" #9 daemon prio=9 os_prio=31 tid=0x7fe50003a800
> nid=0x5603 runnable [0x]
>java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread3" #8 daemon prio=9 os_prio=31
[jira] [Commented] (SUREFIRE-2061) BLOCKED in surefire-forkedjvm-stream-flusher
[
https://issues.apache.org/jira/browse/SUREFIRE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520019#comment-17520019
]
Tibor Digana commented on SUREFIRE-2061:
Hey [~sjaranowski], pls try to find the dump in target/surefire-reports.
It would some exception, I guess, NPE or something similar.
> BLOCKED in surefire-forkedjvm-stream-flusher
>
>
> Key: SUREFIRE-2061
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2061
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Slawomir Jaranowski
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> From time to time test execution is hung up - wait forever ...
> Now I can't reproduce it, test rerun fix it.
> The stack is:
> {code}
> 2022-04-06 13:59:05
> Full thread dump OpenJDK 64-Bit Server VM (25.322-b00 mixed mode):
> "Attach Listener" #16 daemon prio=9 os_prio=31 tid=0x7fe48036a000
> nid=0x380b waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "surefire-forkedjvm-command-thread" #12 daemon prio=5 os_prio=31
> tid=0x7fe504a5c000 nid=0xa803 runnable [0x7db43000]
>java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:255)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0x0005c000ccb0> (a java.io.BufferedInputStream)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0x0005c000ccd8> (a java.io.BufferedInputStream)
> at
> org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleReadableChannel.read(AbstractNoninterruptibleReadableChannel.java:54)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.read(AbstractStreamDecoder.java:487)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.read(AbstractStreamDecoder.java:473)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readMessageType(AbstractStreamDecoder.java:118)
> at
> org.apache.maven.surefire.booter.stream.CommandDecoder.decode(CommandDecoder.java:87)
> at
> org.apache.maven.surefire.booter.spi.CommandChannelDecoder.decode(CommandChannelDecoder.java:67)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:345)
> at java.lang.Thread.run(Thread.java:750)
> "surefire-forkedjvm-stream-flusher" #10 daemon prio=5 os_prio=31
> tid=0x7fe500969000 nid=0xa903 waiting for monitor entry
> [0x7da4]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:117)
> - waiting to lock <0x0005c000d498> (a java.io.BufferedOutputStream)
> at
> org.apache.maven.surefire.api.util.internal.Channels$4.writeImpl(Channels.java:253)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:72)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:45)
> at
> org.apache.maven.surefire.booter.spi.AbstractMasterProcessChannelProcessorFactory$1.run(AbstractMasterProcessChannelProcessorFactory.java:65)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:750)
> "Service Thread" #9 daemon prio=9 os_prio=31 tid=0x7fe50003a800
> nid=0x5603 runnable [0x]
>java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x7fe50001f800
> nid=0x3f03 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x7fe5e800
> nid=0x4103 waiting on
[jira] [Updated] (SUREFIRE-2061) BLOCKED in surefire-forkedjvm-stream-flusher
[
https://issues.apache.org/jira/browse/SUREFIRE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2061:
---
Fix Version/s: 3.0.0-M7
> BLOCKED in surefire-forkedjvm-stream-flusher
>
>
> Key: SUREFIRE-2061
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2061
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> From time to time test execution is hung up - wait forever ...
> Now I can't reproduce it, test rerun fix it.
> The stack is:
> {code}
> 2022-04-06 13:59:05
> Full thread dump OpenJDK 64-Bit Server VM (25.322-b00 mixed mode):
> "Attach Listener" #16 daemon prio=9 os_prio=31 tid=0x7fe48036a000
> nid=0x380b waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "surefire-forkedjvm-command-thread" #12 daemon prio=5 os_prio=31
> tid=0x7fe504a5c000 nid=0xa803 runnable [0x7db43000]
>java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:255)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0x0005c000ccb0> (a java.io.BufferedInputStream)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0x0005c000ccd8> (a java.io.BufferedInputStream)
> at
> org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleReadableChannel.read(AbstractNoninterruptibleReadableChannel.java:54)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.read(AbstractStreamDecoder.java:487)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.read(AbstractStreamDecoder.java:473)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readMessageType(AbstractStreamDecoder.java:118)
> at
> org.apache.maven.surefire.booter.stream.CommandDecoder.decode(CommandDecoder.java:87)
> at
> org.apache.maven.surefire.booter.spi.CommandChannelDecoder.decode(CommandChannelDecoder.java:67)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:345)
> at java.lang.Thread.run(Thread.java:750)
> "surefire-forkedjvm-stream-flusher" #10 daemon prio=5 os_prio=31
> tid=0x7fe500969000 nid=0xa903 waiting for monitor entry
> [0x7da4]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:117)
> - waiting to lock <0x0005c000d498> (a java.io.BufferedOutputStream)
> at
> org.apache.maven.surefire.api.util.internal.Channels$4.writeImpl(Channels.java:253)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:72)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:45)
> at
> org.apache.maven.surefire.booter.spi.AbstractMasterProcessChannelProcessorFactory$1.run(AbstractMasterProcessChannelProcessorFactory.java:65)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:750)
> "Service Thread" #9 daemon prio=9 os_prio=31 tid=0x7fe50003a800
> nid=0x5603 runnable [0x]
>java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x7fe50001f800
> nid=0x3f03 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x7fe5e800
> nid=0x4103 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x7fe4f607e800
> nid=0x3d03 waiting on condition
[jira] [Assigned] (SUREFIRE-2061) BLOCKED in surefire-forkedjvm-stream-flusher
[
https://issues.apache.org/jira/browse/SUREFIRE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-2061:
--
Assignee: Tibor Digana
> BLOCKED in surefire-forkedjvm-stream-flusher
>
>
> Key: SUREFIRE-2061
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2061
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Slawomir Jaranowski
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> From time to time test execution is hung up - wait forever ...
> Now I can't reproduce it, test rerun fix it.
> The stack is:
> {code}
> 2022-04-06 13:59:05
> Full thread dump OpenJDK 64-Bit Server VM (25.322-b00 mixed mode):
> "Attach Listener" #16 daemon prio=9 os_prio=31 tid=0x7fe48036a000
> nid=0x380b waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "surefire-forkedjvm-command-thread" #12 daemon prio=5 os_prio=31
> tid=0x7fe504a5c000 nid=0xa803 runnable [0x7db43000]
>java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:255)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0x0005c000ccb0> (a java.io.BufferedInputStream)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0x0005c000ccd8> (a java.io.BufferedInputStream)
> at
> org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleReadableChannel.read(AbstractNoninterruptibleReadableChannel.java:54)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.read(AbstractStreamDecoder.java:487)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.read(AbstractStreamDecoder.java:473)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readMessageType(AbstractStreamDecoder.java:118)
> at
> org.apache.maven.surefire.booter.stream.CommandDecoder.decode(CommandDecoder.java:87)
> at
> org.apache.maven.surefire.booter.spi.CommandChannelDecoder.decode(CommandChannelDecoder.java:67)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:345)
> at java.lang.Thread.run(Thread.java:750)
> "surefire-forkedjvm-stream-flusher" #10 daemon prio=5 os_prio=31
> tid=0x7fe500969000 nid=0xa903 waiting for monitor entry
> [0x7da4]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:117)
> - waiting to lock <0x0005c000d498> (a java.io.BufferedOutputStream)
> at
> org.apache.maven.surefire.api.util.internal.Channels$4.writeImpl(Channels.java:253)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:72)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:45)
> at
> org.apache.maven.surefire.booter.spi.AbstractMasterProcessChannelProcessorFactory$1.run(AbstractMasterProcessChannelProcessorFactory.java:65)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:750)
> "Service Thread" #9 daemon prio=9 os_prio=31 tid=0x7fe50003a800
> nid=0x5603 runnable [0x]
>java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x7fe50001f800
> nid=0x3f03 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x7fe5e800
> nid=0x4103 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x7fe4f607e800
>
[jira] [Updated] (SUREFIRE-1964) Method filtering support on excludes and includes file
[
https://issues.apache.org/jira/browse/SUREFIRE-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1964:
---
Fix Version/s: 2.22.3
> Method filtering support on excludes and includes file
> --
>
> Key: SUREFIRE-1964
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1964
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Reporter: Ildefonso Montero
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> The current code of Maven Surefire plugin does not provide capabilities for
> performing method filtering on includes/excludes based on files (using
> surefire.excludesFile or surefire.includesFile params)
> Main idea is to provide the same method filtering capabilities that we can
> perform nowadays using the -Dtest parameter but on the mentioned resources
> Thus, if we perform {{mvn test -Dsurefire.excludesFile=/foo/bar/file}} and it
> is using method filtering like:
>
> {code:java}
> test.SomeTest#test1
> test.SomeTest#test2
> test.SomeTest#test3
> test.SomeTest#test4
> test.SomeTest#test5
> test.SomeTest#test6 {code}
> on a project like:
> [https://github.com/jglick/simple-maven-project-with-tests] we obtain:
>
> {{Method filter prohibited in includes|excludes|includesFile|excludesFile
> parameter}}
> With method filtering enabled on these parameters, we will be able to obtain
> {code:java}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running test.SomeTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035
> s - in test.SomeTest
> [INFO] Running test.OtherTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001
> s - in test.OtherTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.808 s
> [INFO] Finished at: 2021-12-03T18:00:37+01:00
> [INFO]
>
> {code}
> were test.SomeTest test methods were directly ignored.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1890) Not compatible with TestNG 7.4.0
[
https://issues.apache.org/jira/browse/SUREFIRE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519243#comment-17519243
]
Tibor Digana commented on SUREFIRE-1890:
[~scoba] The values should be checked according to what is real in TestNG, see
https://github.com/cbeust/testng/blob/master/testng-core-api/src/main/java/org/testng/xml/XmlSuite.java
{code:java}
public enum ParallelMode {
TESTS("tests", false),
METHODS("methods"),
CLASSES("classes"),
INSTANCES("instances"),
NONE("none", false);
{code}
but I think this is not a blocker because the user can avoid using
for NONE.
You can open a PR with the fix on GH.
> Not compatible with TestNG 7.4.0
>
>
> Key: SUREFIRE-1890
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1890
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M5
>Reporter: Joe Barnett
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> TestNG 7.4.0 removed the deprecated method
> {{org.testng.xml.XmlSuite.setParallel(java.lang.String)}}. Trying to run
> tests with parallelism set results in:
> {code:java}
> java.lang.NoSuchMethodError: 'void
> org.testng.xml.XmlSuite.setParallel(java.lang.String)'
> at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:71)
> at
> org.apache.maven.surefire.testng.conf.TestNG510Configurator.configure(TestNG510Configurator.java:40)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:111)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:112)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:145)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519089#comment-17519089
]
Tibor Digana commented on SUREFIRE-2004:
[~kriegaex]
This issue has nothing to do with long development releases.
If the fix not clear, then it is better not to touch the code, otherwise I
break it, and if I break it then the problem is mine and very hard to argue the
next fix. So this issue required some clarification. The problem with M6 was
that we concentrated only on issues reported by the users, then came covid and
I became more less idle in OSS and more active in legal affairs in advocacy of
some people. Today the situation is different because we have got Slawomir, so
we are two active developers. The highest priority is to catch up the plan of
milestones where our tasks would lead to break backwards compatibility (first
inside, then outside in config params).
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-apache-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518917#comment-17518917
]
Tibor Digana commented on SUREFIRE-2029:
Sharing *AtomicInteger *would be possible with
{code:java}
MavenSession.getExecutionProperties()
{code}
It has to be some Java API object and the key value must be in the form of
expression.
The internal forkCount would be shifted by the previous shifts of concurrent
modules started before.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:java}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {code}
> mvn version info:
> {noformat}
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Maven home: /usr/local/apache-maven
> Java version: 11.0.13, vendor: Red Hat, Inc., runtime:
>
[jira] [Comment Edited] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518917#comment-17518917
]
Tibor Digana edited comment on SUREFIRE-2029 at 4/7/22 2:22 PM:
Sharing *AtomicInteger* would be possible with
{code:java}
MavenSession.getExecutionProperties()
{code}
It has to be some Java API object and the key value must be in the form of
expression.
The internal forkCount would be shifted by the previous shifts of concurrent
modules started before.
was (Author: tibor17):
Sharing *AtomicInteger *would be possible with
{code:java}
MavenSession.getExecutionProperties()
{code}
It has to be some Java API object and the key value must be in the form of
expression.
The internal forkCount would be shifted by the previous shifts of concurrent
modules started before.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:java}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
[jira] [Comment Edited] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518886#comment-17518886
]
Tibor Digana edited comment on SUREFIRE-2029 at 4/7/22 1:38 PM:
[~milosh]
Andreas Gudian [~agudian] created this feature. If he meant some guarantees
about isolated projects and -T parameter, coherent behavior across them and
unique numbers, he would implement it so several years ago. He did not mean the
same what you mean now.
He was my colleague in ASF and we talked about it. We know that these
guarantees do not exist for long time.
He wanted to say that the user should not expect limitations in terms of
concurrent JVMs due to these are also controlled by the Maven Core in terms of
parallel modules and the modules are independent, see this sentence:
{noformat}
Maven core allows building modules of multi-module projects in parallel with
the command line option -T. This multiplies the extent of concurrency
configured directly in maven-surefire-plugin.
{noformat}
So, something is under control of the core and some concurrency is controlled
by surefire and the outcome may mean that there would be more than 3 concurrent
JVMs. Maybe 3, maybe 3*N, or even 1 to 3*N.
was (Author: tibor17):
[~milosh]
Andreas Gudian [~agudian] created this feature. If he meant some guarantees
about isolated projects and -T parameter, coherent behavior across them and
unique numbers, he would implement it so several years ago. He did not mean the
same what you mean now.
He was my colleague in ASF and we talked about it. We know for long time these
guarantees do not exist.
He wanted to say that the user should not expect limitations in terms of
concurrent JVMs due to these are also controlled by the Maven Core in terms of
parallel modules and the modules are independent, see this sentence:
{noformat}
Maven core allows building modules of multi-module projects in parallel with
the command line option -T. This multiplies the extent of concurrency
configured directly in maven-surefire-plugin.
{noformat}
So, something is under control of the core and some concurrency is controlled
by surefire and the outcome may mean that there would be more than 3 concurrent
JVMs. Maybe 3, maybe 3*N, or even 1 to 3*N.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
>
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518886#comment-17518886
]
Tibor Digana commented on SUREFIRE-2029:
[~milosh]
Andreas Gudian [~agudian] created this feature. If he meant some guarantees
about isolated projects and -T parameter, coherent behavior across them and
unique numbers, he would implement it so several years ago. He did not mean the
same what you mean now.
He was my colleague in ASF and we talked about it. We know for long time these
guarantees do not exist.
He wanted to say that the user should not expect limitations in terms of
concurrent JVMs due to these are also controlled by the Maven Core in terms of
parallel modules and the modules are independent, see this sentence:
{noformat}
Maven core allows building modules of multi-module projects in parallel with
the command line option -T. This multiplies the extent of concurrency
configured directly in maven-surefire-plugin.
{noformat}
So, something is under control of the core and some concurrency is controlled
by surefire and the outcome may mean that there would be more than 3 concurrent
JVMs. Maybe 3, maybe 3*N, or even 1 to 3*N.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
>
[jira] [Comment Edited] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518507#comment-17518507
]
Tibor Digana edited comment on SUREFIRE-2029 at 4/6/22 11:16 PM:
-
Acctualy ,the documentation talks about this risk.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
Configuration:
{noformat}
3
{noformat}
{noformat}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.
{noformat}
So, essentially, it says that you have 2 modules at least, two modules may run
in parallel, and each surefire plugin has the same config forkCount=3. The
Maven is not able to guarantee that you will have unique number. It could be
possible only if the Maven did not use the ClassWorlds Class Loader, but due to
we use Class Loaders the static context is different and the singletons can not
be shared.
was (Author: tibor17):
Acctualy ,the documentation talks about this risk.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
Configuration:
{noformat}
3
{noformat}
{noformat}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.
{noformat}
So, essentially, it says that you have 2 modules at least, two modules may run
in parallel, and each surefire plugin has the same config forkNumber=2. The
Maven is not able to guarantee that you will have unique number. It could be
possible only if the Maven did not use the ClassWorlds Class Loader, but due to
we use Class Loaders the static context is different and the singletons can not
be shared.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it
[jira] [Comment Edited] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518507#comment-17518507
]
Tibor Digana edited comment on SUREFIRE-2029 at 4/6/22 11:14 PM:
-
Acctualy ,the documentation talks about this risk.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
Configuration:
{noformat}
3
{noformat}
{noformat}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.
{noformat}
So, essentially, it says that you have 2 modules at least, two modules may run
in parallel, and each surefire plugin has the same config forkNumber=2. The
Maven is not able to guarantee that you will have unique number. It could be
possible only if the Maven did not use the ClassWorlds Class Loader, but due to
we use Class Loaders the static context is different and the singletons can not
be shared.
was (Author: tibor17):
Acctualy ,the documentation talks about this risk.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
Configuration:
{noformat}
3
{noformat}
{noformat}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.
{noformat}
So, essentially, it says that you have 2 modules at least, two modules may run
in parallel, and each surefire plugin has the same config forkNumber=2.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique
[jira] [Comment Edited] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518507#comment-17518507
]
Tibor Digana edited comment on SUREFIRE-2029 at 4/6/22 11:12 PM:
-
Acctualy ,the documentation talks about this risk.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
Configuration:
{noformat}
3
{noformat}
{noformat}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.
{noformat}
So, essentially, it says that you have 2 modules at least, two modules may run
in parallel, and each surefire plugin has the same config forkNumber=2.
was (Author: tibor17):
Acctualy ,the documentation talks about this risk.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
Configuration:
{noformat}
3
{noformat}
{noformat}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.
{noformat}
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518507#comment-17518507
]
Tibor Digana commented on SUREFIRE-2029:
Acctualy ,the documentation talks about this risk.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
Configuration:
{noformat}
3
{noformat}
{noformat}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.
{noformat}
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:java}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {code}
> mvn version info:
> {noformat}
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Maven
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518448#comment-17518448
]
Tibor Digana commented on SUREFIRE-2029:
I understand that you want to reach one unique number. It would mean that the
plugin must have a responsibility for the plugins in another POMs, their plugin
executions and Maven execution itself. If anything is changed in Maven, we
have to change this feature in surefire as well. If it happens, it means that
we created unnecessary coupling which is unwanted.
If you want to associate the plugin execution with the name of SQL database, I
would recommend you to use {{project.artifactId}} combined with {{forkNumber}}.
The artifactIds are typically unique in multimodule projects.
Can you guys [~famod] [~milosh] check it out? The interpolation with artifactId
is not supported yet, I guess.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:java}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
>
[jira] [Closed] (SUREFIRE-2060) JDK 18 support
[ https://issues.apache.org/jira/browse/SUREFIRE-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-2060. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=4ce1433c484d268e0c17604a071ad43d27de9e47 > JDK 18 support > -- > > Key: SUREFIRE-2060 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2060 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.22.2 > Environment: Jenkins, Maven >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3 > > > We updated integration tests, JaCoCo to 0.8.7, etc in order to support JDK 18 > in Jenkins. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SUREFIRE-2060) JDK 18 support
Tibor Digana created SUREFIRE-2060: -- Summary: JDK 18 support Key: SUREFIRE-2060 URL: https://issues.apache.org/jira/browse/SUREFIRE-2060 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.22.2 Environment: Jenkins, Maven Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 2.22.3 We updated integration tests, JaCoCo to 0.8.7, etc in order to support JDK 18 in Jenkins. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (SUREFIRE-2059) includeJUnit5Engines and excludeJUnit5Engines have wrong user property
[ https://issues.apache.org/jira/browse/SUREFIRE-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-2059. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=f2d28b80218dc3f9b1222d212ef4fce080faed57 > includeJUnit5Engines and excludeJUnit5Engines have wrong user property > -- > > Key: SUREFIRE-2059 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2059 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 3.0.0-M6 >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M7 > > > The prefix is missing. > _surefire.includeJUnit5Engines_ > _failsafe.includeJUnit5Engines_ > _surefire.excludeJUnit5Engines_ > _failsafe.excludeJUnit5Engines_ > are expected. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SUREFIRE-2059) includeJUnit5Engines and excludeJUnit5Engines have wrong user property
Tibor Digana created SUREFIRE-2059: -- Summary: includeJUnit5Engines and excludeJUnit5Engines have wrong user property Key: SUREFIRE-2059 URL: https://issues.apache.org/jira/browse/SUREFIRE-2059 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin, Maven Surefire Plugin Affects Versions: 3.0.0-M6 Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 3.0.0-M7 The prefix is missing. _surefire.includeJUnit5Engines_ _failsafe.includeJUnit5Engines_ _surefire.excludeJUnit5Engines_ _failsafe.excludeJUnit5Engines_ are expected. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-2057) JPMS Regression: requires static module not include anymore
[ https://issues.apache.org/jira/browse/SUREFIRE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517995#comment-17517995 ] Tibor Digana edited comment on SUREFIRE-2057 at 4/6/22 9:33 AM: Why you marked this as a blocker? Compiler's bug is not a blocker. was (Author: tibor17): Why you marked this as a blocker? > JPMS Regression: requires static module not include anymore > --- > > Key: SUREFIRE-2057 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2057 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 3.0.0-M7 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2057) JPMS Regression: requires static module not include anymore
[ https://issues.apache.org/jira/browse/SUREFIRE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517995#comment-17517995 ] Tibor Digana commented on SUREFIRE-2057: Why you marked this as a blocker? > JPMS Regression: requires static module not include anymore > --- > > Key: SUREFIRE-2057 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2057 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 3.0.0-M7 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (SUREFIRE-2056) BufferOverflowException when encoding message with null testId
[
https://issues.apache.org/jira/browse/SUREFIRE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-2056.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=8e301949173f20971c288484e5711b5496e5df49
> BufferOverflowException when encoding message with null testId
> --
>
> Key: SUREFIRE-2056
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2056
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Yoann Rodière
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> The problem seems to have been introduced here:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-a901d2e995f3d9e7ca75988975cefff9bb5f88686c3d0c8fc8696bc749253e8cR396
> {code}
> int bufferMaxLength = estimateBufferLength(
> eventType.getOpcode().length(), runMode, encoder, 0,
> testRunId == null ? 0 : 1, message );
> {code}
> The buffer estimate seems to ignore the testRunId field completely when the
> testRunId is null, but the {{encodeHeader}} method still adds content to the
> buffer even when the testRunId is null, resulting in a buffer overflow:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-2c1d8cdb8be334b20d2b1befed41ac6776b024a3a8ae040e2413569ead512a21R92-R97
> {code}
> result.put( (byte) ( testRunId == null ? 0 : 1 ) );
> if ( testRunId != null )
> {
> result.putLong( testRunId );
> }
> result.put( (byte) ':' );
> {code}
> Sending a PR shortly.
> Stack trace:
> {noformat}
> java.lang.IllegalStateException: Failed to load ApplicationContext
> at
> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:132)
> at
> org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:124)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:118)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83)
> at
> org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener.prepareTestInstance(SpringBootDependencyInjectionTestExecutionListener.java:43)
> at
> org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:248)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:227)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:246)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:97)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
> at
> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at
[jira] [Assigned] (SUREFIRE-2056) BufferOverflowException when encoding message with null testId
[
https://issues.apache.org/jira/browse/SUREFIRE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-2056:
--
Assignee: Tibor Digana
> BufferOverflowException when encoding message with null testId
> --
>
> Key: SUREFIRE-2056
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2056
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Yoann Rodière
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> The problem seems to have been introduced here:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-a901d2e995f3d9e7ca75988975cefff9bb5f88686c3d0c8fc8696bc749253e8cR396
> {code}
> int bufferMaxLength = estimateBufferLength(
> eventType.getOpcode().length(), runMode, encoder, 0,
> testRunId == null ? 0 : 1, message );
> {code}
> The buffer estimate seems to ignore the testRunId field completely when the
> testRunId is null, but the {{encodeHeader}} method still adds content to the
> buffer even when the testRunId is null, resulting in a buffer overflow:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-2c1d8cdb8be334b20d2b1befed41ac6776b024a3a8ae040e2413569ead512a21R92-R97
> {code}
> result.put( (byte) ( testRunId == null ? 0 : 1 ) );
> if ( testRunId != null )
> {
> result.putLong( testRunId );
> }
> result.put( (byte) ':' );
> {code}
> Sending a PR shortly.
> Stack trace:
> {noformat}
> java.lang.IllegalStateException: Failed to load ApplicationContext
> at
> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:132)
> at
> org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:124)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:118)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83)
> at
> org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener.prepareTestInstance(SpringBootDependencyInjectionTestExecutionListener.java:43)
> at
> org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:248)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:227)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:246)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:97)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
> at
> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
[jira] [Updated] (SUREFIRE-2056) BufferOverflowException when encoding message with null testId
[
https://issues.apache.org/jira/browse/SUREFIRE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2056:
---
Fix Version/s: 3.0.0-M7
> BufferOverflowException when encoding message with null testId
> --
>
> Key: SUREFIRE-2056
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2056
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Yoann Rodière
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> The problem seems to have been introduced here:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-a901d2e995f3d9e7ca75988975cefff9bb5f88686c3d0c8fc8696bc749253e8cR396
> {code}
> int bufferMaxLength = estimateBufferLength(
> eventType.getOpcode().length(), runMode, encoder, 0,
> testRunId == null ? 0 : 1, message );
> {code}
> The buffer estimate seems to ignore the testRunId field completely when the
> testRunId is null, but the {{encodeHeader}} method still adds content to the
> buffer even when the testRunId is null, resulting in a buffer overflow:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-2c1d8cdb8be334b20d2b1befed41ac6776b024a3a8ae040e2413569ead512a21R92-R97
> {code}
> result.put( (byte) ( testRunId == null ? 0 : 1 ) );
> if ( testRunId != null )
> {
> result.putLong( testRunId );
> }
> result.put( (byte) ':' );
> {code}
> Sending a PR shortly.
> Stack trace:
> {noformat}
> java.lang.IllegalStateException: Failed to load ApplicationContext
> at
> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:132)
> at
> org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:124)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:118)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83)
> at
> org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener.prepareTestInstance(SpringBootDependencyInjectionTestExecutionListener.java:43)
> at
> org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:248)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:227)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:246)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:97)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
> at
> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
[jira] [Commented] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516363#comment-17516363
]
Tibor Digana commented on SUREFIRE-2033:
If previous versions executed junit5 tests without platform-runner's annotation
then it means that the {{junit-platform-runner}} can be freely deleted in POM
dependencies.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at: 2022-03-03T09:37:02Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M4 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.619 s
> [INFO] Finished at: 2022-03-03T09:37:37Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M5 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.344 s
> [INFO] Finished at: 2022-03-03T09:38:01Z
> [INFO]
> {code}
> Note the final run above using 3.0.0-M5 and logging: {{Tests run: 0}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1975) JDK18 - The Security Manager is deprecated and will be removed in a future release
[
https://issues.apache.org/jira/browse/SUREFIRE-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1975:
---
Fix Version/s: 2.22.3
> JDK18 - The Security Manager is deprecated and will be removed in a future
> release
> --
>
> Key: SUREFIRE-1975
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1975
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> We won't run the integration test \{{Surefire34SecurityManagerIT}} since of
> JDK 18.
> We won't support SecurityManager in JUnit3 Surefire Provider since of JDK 18.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1426:
---
Fix Version/s: 2.22.3
> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> ---
>
> Key: SUREFIRE-1426
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1426
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Dan Berindei
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
> Attachments: surefire-1426-test.tar.gz
>
>
> We have a reactor with many modules, and also a few random test failures. We
> want to run the tests of all the modules even if a test failed in the core
> module, so we use {{mvn -Dmaven.test.failure.ignore=true}}. {{mvn
> --fail-at-end}} only builds the modules that do not depend on the module with
> a failed test.
> The problem is that fork crashes like this one are written to the surefire
> reports, so Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an
> error in the forked process
> Unable to load category: stress
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:665)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1913) system properties should be restored after the in-process tests have been executed
[ https://issues.apache.org/jira/browse/SUREFIRE-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1913: --- Fix Version/s: 2.22.3 > system properties should be restored after the in-process tests have been > executed > -- > > Key: SUREFIRE-1913 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1913 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1912) user.dir should not be set lazily within the surefire fork JVM
[ https://issues.apache.org/jira/browse/SUREFIRE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1912: --- Fix Version/s: 2.22.3 > user.dir should not be set lazily within the surefire fork JVM > -- > > Key: SUREFIRE-1912 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1912 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > > user.dir is set and overridden by ForkedBooter. > It is already done by setting CWD in the native process. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1908) Wish by Stackoverflow - Documented strategy with parallel Java packages
[ https://issues.apache.org/jira/browse/SUREFIRE-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1908: --- Fix Version/s: 2.22.3 > Wish by Stackoverflow - Documented strategy with parallel Java packages > --- > > Key: SUREFIRE-1908 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1908 > Project: Maven Surefire > Issue Type: Wish > Components: documentation, Junit 4.7+ (parallel) support, Maven > Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > > https://stackoverflow.com/questions/66430769/run-suites-in-parallel-using-maven-failsafe/67113491#67113491 > This is a strategy which allows the users to run several packages in > parallel. The trick is based on Suite of JUnit4. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1865) ChecksumCalculator getSha1 does not compute checksums correctly
[
https://issues.apache.org/jira/browse/SUREFIRE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1865:
---
Fix Version/s: 2.22.3
> ChecksumCalculator getSha1 does not compute checksums correctly
> ---
>
> Key: SUREFIRE-1865
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1865
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Gian Merlino
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> ChecksumCalculator does the following in getSha1:
> {code}
> md.update( configValue.getBytes( ISO_8859_1 ), 0, configValue.length() );
> {code}
> This isn't using the right length, because {{configValue.length()}} is a
> length in characters, not bytes. This will lead to the wrong length being
> used for any strings that contain characters that aren't encoded in a single
> byte.
> Additionally, I believe that this class can be used to compute checksums on
> strings that fall outside the ISO_8859_1 character set, so UTF_8 would be a
> better choice.
> I ran into this when defining a test property that contained Cyrillic
> characters and emojis.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1851) NPE in SmartStackTraceParser causes false positive test results
[ https://issues.apache.org/jira/browse/SUREFIRE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1851: --- Fix Version/s: 2.22.3 > NPE in SmartStackTraceParser causes false positive test results > --- > > Key: SUREFIRE-1851 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1851 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support, JUnit 5.x support, Maven Surefire > Plugin >Reporter: Adam Jones >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > Attachments: junit4.11andsurefire2.22.2.txt, > junit5.7.0andsurefire3.0.0M5.txt > > > If throwing an exception within a test where the stack trace is null, a core > utility (SmartStackTraceParser in comon-java5) will throw an NPE. This will > cause the test suite to fail. > What is especially scary about this is that it will not log that the test has > failed, and in some configurations will even declare the build is successful > and all tests passed. Additionally, the surefire report plugin will declare > all tests passed too. > An exception with a null stacktrace sounds odd, but is easy to do by mocking > an exception with frameworks like Mockito. While people probably shouldn't be > mocking exceptions, it definitely [can and does > happen|https://github.com/search?q=mock%28DataIntegrityViolationException.class%29+language%3AJava+fork%3Afalse=code]. > Not sure what versions exactly are affected. But it's affected the > `common-java5` package since 2012. At least both JUnit 4 and 5 are affected, > with surefire 2.22.1 or 3.0.0-M5. Logs attached. > Can be reproduced with [https://github.com/domdomegg/surefire-1851-demo] > I have a patch ready that I believe fixes this: > https://github.com/apache/maven-surefire/pull/320 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1842) Surefire - NPE at end of successful test run
[ https://issues.apache.org/jira/browse/SUREFIRE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1842: --- Fix Version/s: 2.22.3 > Surefire - NPE at end of successful test run > > > Key: SUREFIRE-1842 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1842 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1, 2.21.0, 2.22.1, 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, > 3.0.0-M4 >Reporter: Jack Leech >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > Attachments: stack_trace.txt, test_profile.xml > > > While using surefire to run a mock test pack all tests are passed, followed > by an exception in the surefire plugin (NPE) at the end which causes the run > to be marked as a failure. > I've tried various surefire versions of surefire and other testing libraries > involved. > I have attached a stack trace of the exception in question and a copy of the > test profile xml. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1659) Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
[
https://issues.apache.org/jira/browse/SUREFIRE-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1659:
---
Fix Version/s: 2.22.3
> Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
> -
>
> Key: SUREFIRE-1659
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1659
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Stig Rohde Døssing
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
> Attachments: src.zip, surefire-stdout-corrupt.zip
>
>
> I have a project that registers a JUnit 5 TestExecutionListener. The
> TestExecutionListener contains an SLF4j Logger, using Log4j2 as the
> underlying library. There is a log4j2.xml on the classpath, logging to
> console, and Surefire is set up to redirect output.
> Running the tests gives the following result.
> {quote}
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file ...
> {quote}
> I've attached a minimal reproduction.
> Doing either of the following eliminates the error:
> * Not having the log4j2.xml on the classpath
> * Not having the Logger in the TestExecutionListener
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1825) Unable to zip the Cucumber TXT report file on Linux and MacOS
[
https://issues.apache.org/jira/browse/SUREFIRE-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1825:
---
Fix Version/s: 2.22.3
> Unable to zip the Cucumber TXT report file on Linux and MacOS
> -
>
> Key: SUREFIRE-1825
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1825
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
> Environment: Nix systems
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> We have the GitHub Workflow (CI system) and we are not able to upload the
> artifacts because the TXT file contains illegal characters.
> {noformat}
> Run actions/upload-artifact@v2-preview
> With the provided path, there will be 20483 files uploaded
> ##[error]Artifact path is not valid:
> /JUnit47WithCucumberIT_testWithParallelClasses/target/surefire-reports/Scenario:
> Do a failing test.txt. Contains character: ":". Invalid characters include:
> ",:,<,>,|,*,?.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1844: --- Fix Version/s: 2.22.3 > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 2.22.3, 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1844: --- Fix Version/s: (was: 2.22.3) > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1844: --- Fix Version/s: 2.22.3 > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 2.22.3, 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1924) Upgrade plexus-java to Version 1.0.7
[ https://issues.apache.org/jira/browse/SUREFIRE-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1924: --- Fix Version/s: 2.22.3 > Upgrade plexus-java to Version 1.0.7 > > > Key: SUREFIRE-1924 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1924 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1967) High resource consumption when executing TestNG tests in parallel mode with a suite file
[ https://issues.apache.org/jira/browse/SUREFIRE-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1967: --- Fix Version/s: 2.22.3 > High resource consumption when executing TestNG tests in parallel mode with a > suite file > > > Key: SUREFIRE-1967 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1967 > Project: Maven Surefire > Issue Type: Bug >Reporter: Piotr Findeisen >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > > When executing TestNG tests with a suite file, TestNG invokes `@AfterClass` > allowing test to free resources, before moving to next test class. > With parallel test execution, at most number-of-thread test classes get > initialized at a time. > When TestNG is invoked from Surefire without a suite file, many test > instances get initialized in sequence, without being torn down, leading to > higher resource consumption. > For resource hungry tests, like in Trino project ( > https://github.com/trinodb/trino/ ) this makes a big difference in resource > consumption. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1890) Not compatible with TestNG 7.4.0
[
https://issues.apache.org/jira/browse/SUREFIRE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1890:
---
Fix Version/s: 2.22.3
> Not compatible with TestNG 7.4.0
>
>
> Key: SUREFIRE-1890
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1890
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M5
>Reporter: Joe Barnett
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> TestNG 7.4.0 removed the deprecated method
> {{org.testng.xml.XmlSuite.setParallel(java.lang.String)}}. Trying to run
> tests with parallelism set results in:
> {code:java}
> java.lang.NoSuchMethodError: 'void
> org.testng.xml.XmlSuite.setParallel(java.lang.String)'
> at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:71)
> at
> org.apache.maven.surefire.testng.conf.TestNG510Configurator.configure(TestNG510Configurator.java:40)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:111)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:112)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:145)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1856) Updated documentation for the TestNG Provider - may not disable JUnit in suiteXmlFiles
[ https://issues.apache.org/jira/browse/SUREFIRE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1856: --- Fix Version/s: 2.22.3 > Updated documentation for the TestNG Provider - may not disable JUnit in > suiteXmlFiles > -- > > Key: SUREFIRE-1856 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1856 > Project: Maven Surefire > Issue Type: Improvement > Components: documentation, Maven Failsafe Plugin, Maven Surefire > Plugin, TestNG support >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1398) TestNG test fails when both JUnitCore provider and TestNG provider are on classpath
[
https://issues.apache.org/jira/browse/SUREFIRE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1398:
---
Fix Version/s: 2.22.3
> TestNG test fails when both JUnitCore provider and TestNG provider are on
> classpath
> ---
>
> Key: SUREFIRE-1398
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1398
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 2.20
>Reporter: Matous Jobanek
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> When both JUnitCore and TestNG providers are on classpath:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.20
>
>
> org.apache.maven.surefire
> surefire-junit47
> 2.20
>
>
> org.apache.maven.surefire
> surefire-testng
> 2.20
>
>
>
> {code}
> then the TestNG execution fails with a message:
> {noformat}
> Configuring TestNG with: TestNG60Configurator
> Cannot use a threadCount parameter less than 1; 1 > 0
> Usage: [options] The XML suite files to run
> Options:
> -configfailurepolicy
>Configuration failure policy (skip or continue)
> -d
>Output directory
> -dataproviderthreadcount
>Number of threads to use when running data providers
> -excludegroups
>Comma-separated list of group names to exclude
> -groups
>Comma-separated list of group names to be run
> -junit
>JUnit mode
>Default: false
> -listener
>List of .class files or list of class names implementing ITestListener
> or
>ISuiteListener
> -methods
>Comma separated of test methods
>Default: []
> -methodselectors
>List of .class files or list of class names implementing
> IMethodSelector
> -mixed
>Mixed mode - autodetect the type of current test and run it with
>appropriate runner
>Default: false
> -objectfactory
>List of .class files or list of class names implementing
>ITestRunnerFactory
> -parallel
>Parallel mode (methods, tests or classes)
>Possible Values: [tests, methods, classes, instances, none, true,
> false]
> -port
>The port
> -reporter
>Extended configuration for custom report listener
> -suitename
>Default name of test suite, if not specified in suite definition file
> or
>source code
> -suitethreadpoolsize
>Size of the thread pool to use to run suites
>Default: 1
> -testclass
>The list of test classes
> -testjar
>A jar file containing the tests
> -testname
>Default name of test, if not specified in suitedefinition file or
> source
>code
> -testnames
>The list of test names to run
> -testrunfactory, -testRunFactory
>The factory used to create tests
> -threadcount
>Number of threads to use when running tests in parallel
> -usedefaultlisteners
>Whether to use the default listeners
>Default: true
> -log, -verbose
>Level of verbosity
> -xmlpathinjar
>The full path to the xml file inside the jar file (only valid if
> -testjar
>was specified)
>Default: testng.xml
> {noformat}
> The same behavior occurs when instead of these two providers I use my own
> dynamic provider and delegate the execution to the TestNG provider.
> The cause of the behavior is a combination of the method
> [convertJunitCoreParameters()|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1289]
> and the TestNG provider.
> The method is called for
> [JunitCoreProvider|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2696]
> and sets the thread count to the current value (no matter if it is set or
> not). In case that it is not set, then the value is 0, which causes the
> before mentioned failure when {{TestNGProvider}} is being executed.
> The same in case of
> [DynamicProvider|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2745]
> In the description of the parameter
> [threadCount|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#threadCount],
>
[jira] [Commented] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516316#comment-17516316
]
Tibor Digana commented on SUREFIRE-2033:
[~roxspring]
You example attached in {{example.zip}} does not contain the annotation
{code:java}
@RunWith
{code}
So there is no adapter from JUnit4 Runner to Junit5 tests and nothing to run of
course.
You example would execute all junit4 unit tests if you wrote them and it would
additionally tun junit5 tests if you used the adapter.
Specifying two surefire providers, i.e. for junit4 and platform, in plugin
dependencies would not make sense with {{junit-platform-runner}} either. So,
since you use {{junit-platform-runner}}, you should remember that still junit4
provider is activated but the you have to use @ RunWith and all the staff
around in order to adapt junit4 runner/provider to junit5 tests. This is the
purpose of {{junit-platform-runner}} in my understaning and it is used for
migration from junit4 to junit5, but final is final after all the classes are
migrated and then {{junit-platform-runner}} has to be deleted. This is I think
the main business purpose of {{junit-platform-runner}}.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at: 2022-03-03T09:37:02Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M4 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.619 s
> [INFO] Finished at: 2022-03-03T09:37:37Z
> [INFO]
>
> % mvn
[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516289#comment-17516289
]
Tibor Digana commented on SUREFIRE-2004:
[~gzm55]
I am sorry but we are already on the mailing list with the release Vote.
I analysed the code but I was not totally sure about this business feature, so
I dedicated my time to the plan with milestones.
Now we know what lines of code should be touched, there are two potentional
fixes but this fix would require the developer to debug the code because there
are some open questions about the code. It would be worth to debug the code,
compare the flow in both one-pom, multiple-poms are make the decision about the
fix.
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-apache-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516282#comment-17516282
]
Tibor Digana commented on SUREFIRE-2004:
[~kriegaex]
I do not expect your feedback. It is opposite :-)
We will give you our feedback.
Last days I have assigned several issues to the backlog as they suddenly
appeared during the release Vote 3.0.0-M6 but they are not related to this
release Vote. We only do not want to forget these issues, and we will have a
chance to have a look at them during the next development iteration.
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516168#comment-17516168
]
Tibor Digana edited comment on SUREFIRE-2033 at 4/2/22 12:10 AM:
-
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 tests to the junit5 tests which is his target
what he is aiming for. The documentation often describes POM configuration and
dependencies. I believe that the user would understand the principles and he
would better help himself.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
It is not worth to use {{junit-platform-runner}} if your tests are completely
written in JUnit5 and no JUnit4 tests. Then you should delete the
{{junit-platform-runner}} from the code, means some JUnit4 Suite class, and
from dependencies, and you would obtain nice full version of JUnit5 tests and
Surefire would automatically activate JUnit5 provider for you. This was my
meaning. So that the {{junit-platform-runner}} is useful for some intermediate
time but it should not be something long lasting in the project.
was (Author: tibor17):
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 tests to the junit5 tests which is his target
what he is aiming for. The documentation often describes POM configuration and
dependencies. I believe that the user would understand the principles and he
would better help himself.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO]
[jira] [Comment Edited] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516168#comment-17516168
]
Tibor Digana edited comment on SUREFIRE-2033 at 4/1/22 11:44 PM:
-
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 tests to the junit5 tests which is his target
what he is aiming for. The documentation often describes POM configuration and
dependencies. I believe that the user would understand the principles and he
would better help himself.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
was (Author: tibor17):
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 tests to the junit5 tests which is his target
what he is aiming for.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD
[jira] [Comment Edited] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516168#comment-17516168
]
Tibor Digana edited comment on SUREFIRE-2033 at 4/1/22 11:33 PM:
-
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 tests to the junit5 tests which is his target
what he is aiming for.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
was (Author: tibor17):
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 test to the junit5 test which is his target
what he is aiming for.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
[jira] [Commented] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516168#comment-17516168
]
Tibor Digana commented on SUREFIRE-2033:
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 test to the junit5 test which is his target
what he is aiming for.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at: 2022-03-03T09:37:02Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M4 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.619 s
> [INFO] Finished at: 2022-03-03T09:37:37Z
> [INFO]
>
> % mvn test
[jira] [Comment Edited] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516164#comment-17516164
]
Tibor Digana edited comment on SUREFIRE-1879 at 4/1/22 11:19 PM:
-
ok, bad luck, we have to investigate it better. It would not be that easy, I
think.
was (Author: tibor17):
ok, bad luck, we have to investigate it better. It would not be easy, I think.
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516164#comment-17516164
]
Tibor Digana commented on SUREFIRE-1879:
ok, bad luck, we have to investigate it better. It would not be easy, I think.
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1651) JUnit5 Vintage + Maven-Failsafe + Category = ???
[
https://issues.apache.org/jira/browse/SUREFIRE-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1651:
---
Fix Version/s: waiting-for-feedback
> JUnit5 Vintage + Maven-Failsafe + Category = ???
>
>
> Key: SUREFIRE-1651
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1651
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Torsten Mingers
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: IntegrationTestJUnit5Vintage.zip
>
>
> I finally managed to switch our test infrastructure to JUnit5. Strictly
> speaking, it is the first step and the "old" tests are all still JUnit4 and
> run via the Vintage engine.
> I currently have a problem with this combination.
>
> *Some details:*
> We separate unit tests and integration tests with @Category annotations and
> then filter them out in Surefire and Failsafe. I'll add the setup below.
> Since the change to JUnit5-Vintage, filtering has stopped working and all
> tests are always running.
> In JUnit5 the filtering happens via Tags. I can not specify these in
> JUnit4-based tests.
> According to the JUnit5 documentation, the categories should continue to
> work:
> https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4-categories-support
> However, in the documentary of Surefire (or Failsafe) only tags covered:
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
> The configuration for JUnit5 tags is done in _groups_ as previously with the
> categories in JUnit4. But the configuration does not seem to work when using
> JUnit5 Vintage engine to run the tests.
> Is there a way to configure the Maven Failsafe and Surefire plugins to work
> with tags *and* categories?
> For a hint, I would be very grateful.
>
> *Configuration used*
> {code}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.22.1
>
>
> **/*.class
>
>
> net.veda.horizon.test.IntegrationTest,
> net.veda.horizon.test.IntegrationTestGraphDB,
> net.veda.horizon.test.IntegrationPermissionTest
>
>
>
>
> ...
>
>
> integrationtest
>
>
> integrationTest
>
>
>
>
>
>
> org.apache.maven.plugins
>
> maven-failsafe-plugin
> 2.19.1
>
>
>
> **/*.java
>
>
> net.veda.horizon.test.IntegrationTest
>
>
> ...
>
>
>
>
>
> ...
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1879:
---
Fix Version/s: waiting-for-feedback
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2029:
---
Fix Version/s: waiting-for-feedback
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:java}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {code}
> mvn version info:
> {noformat}
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Maven home: /usr/local/apache-maven
> Java version: 11.0.13, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-11-openjdk-11.0.13.0.8-1.el7_9.x86_64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-1160.53.1.el7.x86_64", arch: "amd64",
> family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2004:
---
Fix Version/s: waiting-for-feedback
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1266) Specifying groups shouldn't require junit on classpath if no test classes
[
https://issues.apache.org/jira/browse/SUREFIRE-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1266:
---
Fix Version/s: waiting-for-feedback
> Specifying groups shouldn't require junit on classpath if no test classes
> -
>
> Key: SUREFIRE-1266
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1266
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.19.1
> Environment: Windows 7, Oracle JDK 1.8.0_40, Maven 3.3.3
>Reporter: Anders Hammar
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Test framework: junit 4.8+
> I have a scenario where we want to configure the groups parameter in a parent
> so that it doesn't have to be specified in all modules. However, not all
> modules have test classes and therefore no dependency on junit is specified
> in those projects. What then happens is that m-surefire-p fails with:
> {quote}
> groups/excludedGroups require TestNG or JUnit48+ on project test classpath
> {quote}
> This can be worked around by specifying skipTests on those projects, but it's
> a bit cumbersome.
> It would be nice if surefire could detect that there are no test classes
> (src/test/main is empty) and therefore the project should just be ignored.
> However, I guess there could be test classes in a dependency so that might
> not be as easy.
> Possibly the solution could be to not fail the surefire execution if
> groups/excludedGroups is set but TestNG or JUnit 4.8+ is not on the
> classpath, but issue a warning message and ignoring it?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515847#comment-17515847
]
Tibor Digana commented on SUREFIRE-2029:
If you use parallel Maven build, i.e. -T... , the forkNumbers may repeat.
The reason is that the idea behind Maven assumes that plugins are very isolated
and should not have any notion about the surrounding world, basically.
So I guess, the execution would be safe if you avoid using -T ...
See our integration test ForkModeIT and the pattern
{noformat}
"testValue_${surefire.threadNumber}_${surefire.forkNumber}"
{noformat}
which is resolved to testValue_1_1.
It is a combination of parallel test and parallel forks.
If the Maven API provides us with -T number on particular POm execution, we may
extend this patter. This was incremental work in passed as well.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:java}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515736#comment-17515736
]
Tibor Digana commented on SUREFIRE-2004:
[~gzm55]
As it seems, [~kriegaex] has a simple project with single POM which does not
work but multi-module project works. It would be worth to debug a reproducible
project because there we can better decide on the fix.
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515643#comment-17515643
]
Tibor Digana edited comment on SUREFIRE-1879 at 4/1/22 12:15 AM:
-
[~famod]
Falko, you often support Maven. The Maven is certainly the project you like and
you use Maven. You was never thinking about to join us in development?
was (Author: tibor17):
[~famod]
Falco, you often support Maven. The Maven is certainly the project you like and
you use Maven. You was never thinking about to join us in development?
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515643#comment-17515643
]
Tibor Digana commented on SUREFIRE-1879:
[~famod]
Falco, you often support Maven. The Maven is certainly the project you like and
you use Maven. You was never thinking about to join us in development?
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515642#comment-17515642
]
Tibor Digana commented on SUREFIRE-1879:
The plugin process did not wait for surefire forked JVM and so the logs could
be lost. Now this is fixed in 3.0.0-M6. Pls check it out with 3.0.0-M6. There
is a release vote with latest version, pls use the plugin repo as stated in the
Vote, https://lists.apache.org/thread/60j5vr86y9o24yoj4665gy1rylb7865g
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (SUREFIRE-1877) Can't print from a shutdown hook
[ https://issues.apache.org/jira/browse/SUREFIRE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1877. -- Assignee: Tibor Digana Resolution: Duplicate > Can't print from a shutdown hook > > > Key: SUREFIRE-1877 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1877 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M5 >Reporter: Stuart Douglas >Assignee: Tibor Digana >Priority: Major > > In surefire 3.0.0-M5 any test output from a shutdown hook is not printed to > the console, and is effectively lost, while this worked in 2.22. > > For some background my use case is automatically generating Jacoco reports in > a shutdown hook without needing to configure a heap of different maven tasks > (so that when using Quarkus Jacoco will 'just work' with no additional config > required), my code just waits for the Jacoco agent to finish writing its > data, then generates the report. If something goes wrong with this process > any error is lost. > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1266) Specifying groups shouldn't require junit on classpath if no test classes
[
https://issues.apache.org/jira/browse/SUREFIRE-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515620#comment-17515620
]
Tibor Digana commented on SUREFIRE-1266:
[~cipi]
Why you closed it?
Now we are free because there is a pending Release Vote on the mailing list.
I have noticed your ticket in the email.
> Specifying groups shouldn't require junit on classpath if no test classes
> -
>
> Key: SUREFIRE-1266
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1266
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.19.1
> Environment: Windows 7, Oracle JDK 1.8.0_40, Maven 3.3.3
>Reporter: Anders Hammar
>Priority: Major
>
> Test framework: junit 4.8+
> I have a scenario where we want to configure the groups parameter in a parent
> so that it doesn't have to be specified in all modules. However, not all
> modules have test classes and therefore no dependency on junit is specified
> in those projects. What then happens is that m-surefire-p fails with:
> {quote}
> groups/excludedGroups require TestNG or JUnit48+ on project test classpath
> {quote}
> This can be worked around by specifying skipTests on those projects, but it's
> a bit cumbersome.
> It would be nice if surefire could detect that there are no test classes
> (src/test/main is empty) and therefore the project should just be ignored.
> However, I guess there could be test classes in a dependency so that might
> not be as easy.
> Possibly the solution could be to not fail the surefire execution if
> groups/excludedGroups is set but TestNG or JUnit 4.8+ is not on the
> classpath, but issue a warning message and ignoring it?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-1651) JUnit5 Vintage + Maven-Failsafe + Category = ???
[
https://issues.apache.org/jira/browse/SUREFIRE-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515533#comment-17515533
]
Tibor Digana edited comment on SUREFIRE-1651 at 3/31/22 7:25 PM:
-
I used the version {{3.0.0-M6}} but also I used the original versions, and I
have to say that the project works for me, pls see my logs below.
{{mvn verify -P integrationtest}}
The groups are documented in
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#Filtering_by_Tags
These groups are transparent to the platform engine. Surefire does not
distinguish between engines. Surefire Provider does not know if you use Jupiter
or Vintage or any other engine. We only execute the JUnit5 Platform Launcher
and the responsibility is finished at this level. Then the Platform Launcher
has to pickup engine implementation. The Surefire and Failsafe passed a filter
to the Launcher execution and the Surefire Provider only calls execution method
of the Launcher by passing certain test class.
Upon this, you should understand that the responsibility for the groups is at
the level of junit5 engine implementation. We do not control the execution of
the test. We only invoke the execution of the Launcher and we also verify the
groups in our integration tests but we do not make any difference between the
engines, we are not able to and we do not need it. This means that JUnit5's
functionality as tags/groups should be additionally discussed with the Junit
team if a bug exists. Sometimes we do it if there are TestNG issues and the
TestNG team cooperates with us very well. This is nothing new for us.
{noformat}
[INFO] --- maven-surefire-plugin:3.0.0-M6:test (default-test) @
IntegrationTestJUnit5Vintage ---
[INFO] Using auto detected provider
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running net.veda.test.testIntegrationTestIsUnitTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.045 s
- in net.veda.test.testIntegrationTestIsUnitTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @
IntegrationTestJUnit5Vintage ---
[INFO] Building jar:
c:\vcs\IntegrationTestJUnit5Vintage\target\IntegrationTestJUnit5Vintage-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-failsafe-plugin:3.0.0-M6:integration-test (default) @
IntegrationTestJUnit5Vintage ---
[INFO] Using auto detected provider
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running net.veda.test.testIntegrationTestIsIntegrationTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 s
- in net.veda.test.testIntegrationTestIsIntegrationTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] --- maven-failsafe-plugin:3.0.0-M6:verify (default) @
IntegrationTestJUnit5Vintage ---
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 7.981 s
[INFO] Finished at: 2022-03-31T21:08:47+02:00
[INFO]
{noformat}
was (Author: tibor17):
I used the version {{3.0.0-M6}} but also I used the original versions, and I
have to say that the project works for me, pls see my logs below.
{{mvn verify -P integrationtest}}
The groups are documented in
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#Filtering_by_Tags
These groups are transparent to the platform engine. Surefire does not
distinguish between engines. Surefire Provider does not know if you use Jupiter
or Vintage or any other engine. We only execute the JUnit5 Platform Launcher
and the responsibility is finished at this level. Then the Platform Launcher
has to pickup engine implementation.
Surefire and Failsafe passed a filter to the Launcher execution and the
Surefire Provider only calls execution method of the Launcher by passing
certain test class.
Upon this, you should understand that the responsibility for the groups is at
the level of junit5 engine implementation. We do not control the execution of
the test. We only invoke the execution of the Launcher and we also verify the
groups in our integration tests but we do not make any difference between the
engines, we are not able to and we do not need it. This means that JUnit5's
functionality as tags/groups should be additionally discussed
