[
https://issues.apache.org/jira/browse/SUREFIRE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600071#comment-17600071
]
Niels Basjes commented on SUREFIRE-2073:
----------------------------------------
I ran into something that seems very similar to this issue.
I put the smallest reproduction I could create here:
[https://github.com/nielsbasjes/MavenSurefireForkCount]
My key question: Did I run into this issue, or is this something different?
> 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.10#820010)
