Read ConfigurationParameters from properties file in classpath

[marcphilipp]

Overview

The discussion in #905 has brought to light that some test authors would like to configure different default values for the test instance lifecycle etc. without being forced to annotate each and every test class.

ConfigurationParameters already allows one to specify parameters for test engines. It currently uses JVM system properties as a fallback mechanism if a requested parameter is not explicitly provided when building a discovery request. However, system properties need to be specified for every launch configuration in an IDE, etc. which is often cumbersome and repetitive.

So, in addition to explicit parameters and system properties, we should read configuration parameters from a classpath resource called junit-platform.properties that could look like this:

junit.jupiter.conditions.deactivate = org.junit.jupiter.*
junit.jupiter.extensions.autodetection.enabled = true
junit.jupiter.testinstance.lifecycle.default = per_class

Configuration Parameter Resolution

The lookup in LauncherConfigurationParametersfor a config parameter would check the following sources in this order:

1. explicitly specified parameters
2. system properties
3. config file

So, only if a parameter is neither explicitly specified nor present as a system property, would it be read from the config file.

Deliverables

• Read ConfigurationParameters from properties file in the classpath.
  • Ensure proper resolution order.
  • Log INFO message if properties file detected.
  • Update JavaDoc for ConfigurationParameters.
• Document in the User Guide.
• Document in the release notes.

[sbrannen]

Tentatively slated for 5.0 RC3 now, for potential inclusion prior to 5.0 GA.

[kcooney]

What's the expected behavior if there are multiple junit-platform.properties files on the classpath? I can imagine third-party libraries accidentally including one in their jar.

Do we want a preferred format to specify settings that are package-specific? I can imagine developers wanting to change the default test lifecycle for a package tree for integration tests. Possibly a format similar to a logging properties file?

[sbrannen]

in progress

[sbrannen]

What's the expected behavior if there are multiple junit-platform.properties files on the classpath?

We will simply implement "first one wins" behavior.

I can imagine third-party libraries accidentally including one in their jar.

I don't foresee that as likely, and if it did occur that would be a bug in the third-party library.

FWIW, I have never heard of any such issues with Spring's spring.properties file, and that's analogous to what we aim to support here.

[sbrannen]

Do we want a preferred format to specify settings that are package-specific?

The goal of this issue is simply to provide a straightforward means for setting configuration parameters on the JUnit Platform using a persistent format: we are not addressing any of the existing configuration parameters supported by JUnit Jupiter in this issue.

I can imagine developers wanting to change the default test lifecycle for a package tree for integration tests. Possibly a format similar to a logging properties file?

If we want to support test instance lifecycle configuration at the package level, I think we should address that as a separate issue and simply look up @TestInstance on packages.

[sbrannen]

FYI: the code is done and available here: 3e9376b

All that's left is documentation. 😉

[kcooney]

I can imagine third-party libraries accidentally including one in their jar.

I don't foresee that as likely, and if it did occur that would be a bug in the third-party library.
FWIW, I have never heard of any such issues with Spring's spring.properties fil

@sbrannen FWIW, it seems to be quite common for logging properties files:

• Remove log4j.properties from droid-core-interface digital-preservation/droid#176
• Do not include log4j.properties in JARs marytts/marytts#711
• Dont include logging.properties in opensocial.jar Garoid/opensocial-java-client#28
• remove logging.properties from vaadin-sass-compiler root package vaadin/sass-compiler#258

I suggest using ClassLoader.findResources() to find the property file, and log a warning if there is more than one instance on the classpath.

[sbrannen]

I suggest using ClassLoader.findResources() to find the property file, and log a warning if there is more than one instance on the classpath.

Alrighty. I'll see if I can make it a bit more robust.

Cheers,

Sam

[sbrannen]

@kcooney, I switched to using ClassLoader.getResources() (ClassLoader.findResources() is a protected method 😉) in my most recent commit (4d9b029).

[sbrannen]

Resolved in master in commit df92b77.