Repository navigation
Support multiple junit-platform.properties on the classpath #2794
Description
I implemented a ClassOrderer for Quarkus and the idea was to enable that orderer by default for all Quarkus users (and also for the Quarkus CI).
But I overlooked the fact that junit-platform.properties is only expected once on the classpath and if there already is a project-specific properties file (e.g. with junit.jupiter.extensions.autodetection.enabled) there are many warnings issued by this code: https://github.com/junit-team/junit5/blob/r5.8.2/junit-platform-launcher/src/main/java/org/junit/platform/launcher/core/LauncherConfigurationParameters.java#L232-L236
Btw, that orderer is configurable, so the original idea also was to just add (as a Quarkus user) a custom junit-platform.properties to your project with only the respective property (without repeating junit.jupiter.testclass.order.default).
It would come in very handy if all junit-platform.properties on the classpath would be merged, in the order as they appear on the cp.
I'm not sure whether a flag to go back to the previous behavior would be required, which is a bit of a chicken and egg situation I guess (where to put it?).
Activity
famod commentedon Dec 12, 2021
stale commentedon Dec 13, 2022
stefanrybacki commentedon Dec 13, 2022
famod commentedon Jan 30, 2023
mpkorstanje commentedon Jan 31, 2023
Note: Not part of the JUnit team.
It seems to me that depending on the classpath order to determine the configuration of JUnit is fraught with unpredictability and would make it hard to reason about the effective configuration.
However the JUnit Platform accepts configuration from a few different sources, the properties file being only one of them.
Now I'm not familiar with Quarkus but I would expect that all projects inherit from some parent-pom. Have you considered providing the property through Surefire instead?
famod commentedon Jan 31, 2023
There is no parent pom in Quarkus but a BOM instead (which cannot transport plugin config).
Generated apps could be covered this way, but:
a) not everyone uses that generation
b) there are many existing projects out there
c) surefire config is not picked automatically in Eclipse IDE (and maybe others)
PS: ...and there is also Gradle.
marcelstoer commentedon Jan 3, 2024
We were just bitten by this as well. Our project (transitively) depends on
io.quarkus:quarkus-junit5-propertieswhich ships ajunit-platform.properties(source). This now clashes with our own file.👍
This is particularly so as the JUnit guide warns "It is therefore recommended to change the default in the JUnit Platform configuration file instead of via a JVM system property."
At the moment, the only sensible remedy appears to be to exclude the Quarkus dependency and to copy-paste their JUnit instructions into our
junit-platform.properties.28 remaining items
cdprete commentedon Aug 9, 2024
I agree.
In the meantime, I've opened a ticket on their issue tracker: https://issues.apache.org/jira/browse/KAFKA-17307 with https://github.com/cdprete/kafka-junit-platform-props as minimal example.
cdprete commentedon Aug 9, 2024
@sbrannen A naïve idea would be to assign the priority based on the path where the files have been found.
The further they're away from the current working (or, better, sub-module in case of multi-module projects) directory, the less important they're.
In such a scenario, "your own" file will be the one having the shortest path.
Moreover, configs within JARs (aka from some sort of direct or transitive dependency) could have less priority by default.
mumrah commentedon Sep 17, 2024
Hello from Apache Kafka 👋 😄. I came across this thread while trying to figure out why we were seeing this warning in our build. I agree we should not be shipping this file in our test jars (I upgraded the priority of KAFKA-17307).
What we were attempting to do was set a default JUnit property for all of our tests. What is the recommended approach here? We have a multi-project Gradle build with a fairly complex tree of dependencies. Perhaps we need to introduce a
testRuntimeOnlyproject dependency that includes this file as a resource?marcphilipp commentedon Sep 23, 2024
@mumrah Yes, that sounds like a sensible solution. Another would be to exclude
junit-platform.propertieswhen creating the test jar.cdprete commentedon Sep 26, 2024
@mumrah I would probably simply adapt the Gradle task responsible of creating the test-jar to not include such a file as @marcphilipp said.
This should be even safer for Maven projects since there is no test-runtime scope in Maven.
Another option would maybe be to configure the Gradle test runner to pass these properties as system properties, so that the file is not needed at all.
mumrah commentedon Sep 26, 2024
Turns out, this was solved a little while ago in Kafka (KAFKA-17121) by explicitly excluding the file from the JARs. In the upcoming 3.9 release, this should no longer be a problem.
seregamorph commentedon Dec 23, 2024
Facing the same problem with https://github.com/seregamorph/spring-test-smart-context/blob/master/spring-test-smart-context/src/main/resources/junit-platform.properties
This project defines own sorter of spring integration test classes grouped sequentially by their context configurations (and eagerly closing context on last test per each config). The idea is pretty similar to what @famod explains in the topic starting message and by design the project using this micro-framework just needs to declare a single dependency without any other special configuration, that's it.
As a failover logic for now I plan to make auto-diagnostics that will detect multiple
junit-platform.propertiesand give guidance. But in general it would be great to have some generic solution there.marcphilipp commentedon Jan 2, 2025
@seregamorph Thanks for sharing that use case! In your case you'd probably want that to be used but be able to override the sorter for your tests, if necessary, right?
seregamorph commentedon Jan 2, 2025
The project provides its own
junit-platform.propertiesin the classpath to auto-configure the test sorting, yes. And this sorting is mandatory, because this way the library discovers the full set of test classes (which should be known ahead before executing them). So the basic instruction is simple: just add a dependency and all the magic will happen automatically (it also discovers spring test execution listeners fromspring.factories).But what can happen in a project that has own
junit-platform.propertiesor it potentially comes from another third-party likespring-kafka-test(even if these configurations don't conflict to each other as they declare different parameters): the sorting is not applied (but it's a key feature for the library to properly sort tests) and in the best case there will be a warning from junit-platform core about duplication. But as you understand, for library user it can be not very helpful.This is especially possible in a huge codebase, where the optimization with test reordering and eager context closing makes the best possible effect (actually that's how I discovered the problem - just added a library to Adyen codebase :) ).
holly-cummins commentedon Jun 4, 2025
I suspect that in many cases the properties in the two files would not conflict (except for maybe class orderers). Maybe the best solution is to still print a warning, but also aggregate the contents of the two files? This isn't perfect, but it avoids the case where one of the files is completely ignored. I'd be happy to do a PR if that solution is agreeable.
holly-cummins commentedon Apr 14, 2026
I've created #5559, which I think resolves this relatively safely. The behaviour preserves the current behaviour when individual properties conflict, but ensures that the presence of a
junit-platform.propertiesfile in a dependency doesn't stop a project's properties from being read.marcphilipp commentedon Apr 20, 2026
We discussed this issue in last week's team call.
We're aligned on the following design goals:
junit-platform.properties).We're not convinced that merging multiple
junit-platform.propertiesfiles is the right solution or at least not yet. Before working towards a general solution (which may or may not be merging properties), we'd like to focus on the use case of supporting defaultClassOrderers. @sbrannen will pick that up in the near future.junit-platform.propertieslocation #2195