Introduce support for configuration parameters in console launcher and build plugins

[sbrannen]

Overview

As discussed in #905 (comment), there is currently no native support for setting a configuration parameter via the console launcher, Maven Surefire plugin, or Gradle plugin.

Thus, the only option from the build perspective is to set a system property or rely on the presence of a JUnit Platform configuration file (see #1003).

For the JUnit Platform Gradle Plugin, you can set such a system property via a work-around that is discussed in #475 (comment).

Proposal

ConsoleLauncher

Introduce a --config command line option that expects a key=value pair.

java -jar junit-platform-console-standalone-*.jar \
     --config junit.jupiter.extensions.autodetection.enabled=true \
     --config junit.jupiter.testinstance.lifecycle.default=per_class

Gradle

Align with the syntax supported for JVM system properties by Gradle tasks:

systemProperty('java.util.logging.manager', 'org.apache.logging.log4j.jul.LogManager')

This gives us:

junitPlatform {
  // ...
  configurationParameter('junit.jupiter.extensions.autodetection.enabled', 'true')
  configurationParameter('junit.jupiter.testinstance.lifecycle.default', 'per_class')
  // ...
}

Note, however, that the parentheses are optional in Groovy resulting in the following alternative syntax being supported out of the box.

junitPlatform {
  // ...
  configurationParameter 'junit.jupiter.extensions.autodetection.enabled', 'true'
  configurationParameter 'junit.jupiter.testinstance.lifecycle.default', 'per_class'
  // ...
}

Maven

Surefire does not support nested structures within properties, but that's not an issue if we take inspiration from Spring's support for inlined Properties in XML configuration, resulting in the following.

// ...
<build>
    <plugins>
        // ...
        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.19</version>
            <configuration>
                <properties>
                    <excludeTags>integration, regression</excludeTags>
                    <configurationParameters>
                      junit.jupiter.extensions.autodetection.enabled = true
                      junit.jupiter.testinstance.lifecycle.default = per_class
                    </configurationParameters>
                </properties>
            </configuration>
            <dependencies>
                // ...
            </dependencies>
        </plugin>
    </plugins>
</build>
// ...

For an example of how the configurationParameters can be converted to a Map<String, String> with full support for the java.util.Properties syntax, see #1015 (comment).

Deliverables

• Introduce support for setting configuration parameters in the console launcher.
• Introduce support for setting configuration parameters in the JUnit Platform Gradle Plugin.
• Introduce support for setting configuration parameters in the Maven Surefire Plugin.
• Update User Guide.
• Update release notes.
• Prepare sample projects.

[marcphilipp]

I've updated the issue description with proposals for Console Launcher, Gradle, and Maven.

ConsoleLauncher

java -jar junit-platform-console-standalone-*.jar \
     --config junit.jupiter.extensions.autodetection.enabled=true \
     --config junit.jupiter.testinstance.lifecycle.default=PER_CLASS

Gradle

junitPlatform {
  // ...
  configurationParameters = [
    'junit.jupiter.extensions.autodetection.enabled': 'true',
    'junit.jupiter.testinstance.lifecycle.default': 'PER_CLASS'
  ]
  // ...
}

OR

junitPlatform {
  // ...
  configurationParameters['junit.jupiter.extensions.autodetection.enabled'] = 'true'
  configurationParameters['junit.jupiter.testinstance.lifecycle.default'] = 'PER_CLASS'
  // ...
}

Maven

Since Surefire does not support nested structures within properties our best option seems to be to do nothing and rely on the existing support for system properties.

...
<build>
    <plugins>
        ...
        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.19</version>
            <configuration>
                <systemPropertyVariables>
                    <junit.jupiter.extensions.autodetection.enabled>true</junit.jupiter.extensions.autodetection.enabled>
                    <junit.jupiter.testinstance.lifecycle.default>PER_CLASS</junit.jupiter.testinstance.lifecycle.default>
                </systemPropertyVariables>
                <properties>
                    <excludeTags>integration, regression</excludeTags>
                </properties>
            </configuration>
            <dependencies>
                ...
            </dependencies>
        </plugin>
    </plugins>
</build>
...

[sbrannen]

Proposal Review

ConsoleLauncher

I think --config is perfect.

Gradle

I think we should follow the same syntax supported for JVM system properties by Gradle tasks:

systemProperty('java.util.logging.manager', 'org.apache.logging.log4j.jul.LogManager')

This would give us:

junitPlatform {
  // ...
  configurationParameter('junit.jupiter.extensions.autodetection.enabled', 'true')
  configurationParameter('junit.jupiter.testinstance.lifecycle.default', 'per_class')
  // ...
}

Maven

I'm not a Surefire expert, but I honestly do not like relying on JVM system properties for this (unless there is literally no alternative). Rationale: system properties are technically not a first-class citizen in ConfigurationParameters and would never show up in invocations of toString() (e.g., while debugging or if we later decide to log the contents of ConfigurationParameters at start-up (which I think is actually a good idea)).

[sbrannen]

I've updated the issue description with proposals for Console Launcher, Gradle, and Maven.

Thanks, @marcphilipp! 👍

[sbrannen]

Note that the parentheses are optional in my proposal for Gradle:

  // configurationParameter('junit.jupiter.extensions.autodetection.enabled', 'true')
  configurationParameter 'junit.jupiter.extensions.autodetection.enabled', 'true'

[sbrannen]

Alternative Proposal for Maven

Since Surefire does not support nested structures within properties our best option seems to be to do nothing and rely on the existing support for system properties.

We don't actually need a nested structure for this use case.

Rather, we can take inspiration from Spring's support for inlined Properties in XML configuration, resulting in the following.

...
<build>
    <plugins>
        ...
        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.19</version>
            <configuration>
                <properties>
                    <excludeTags>integration, regression</excludeTags>
                    <configurationParameters>
                      junit.jupiter.extensions.autodetection.enabled = true
                      junit.jupiter.testinstance.lifecycle.default = per_class
                    </configurationParameters>
                </properties>
            </configuration>
            <dependencies>
                ...
            </dependencies>
        </plugin>
    </plugins>
</build>
...

It's then straightforward to read in the String content of the configurationParameters key in the map returned by org.apache.maven.surefire.providerapi.ProviderParameters.getProviderProperties() and load a Properties object by treating the entire content as an in-memory file. The contents of the Properties object can then be converted into a Map<String,String> which is then passed to the Launcher API. That could look something like the following (authored in the web browser and therefore not compiled or tested).

Map<String, String> configParams = new HashMap<>();

String content = this.parameters.getProviderProperties().get("configurationParameters");

try (StringReader reader = new StringReader(content))  {
	Properties props = new Properties();
	props.load(reader);
	props.forEach((key, value) -> configParams.put(String.valueOf(key), String.valueOf(value)));
}
catch (IOException ex) {
	// TODO Log warning.
}

// pass configParams to LauncherDiscoveryRequestBuilder.configurationParameters()

[marcphilipp]

I'm in favor of both the alternative proposals for Gradle and Maven.

Thanks, @sbrannen! 👍

[sbrannen]

Update: replaced original proposals in this issue's description with my alternative proposals.