Provide mechanism for configuring custom plugins

[hcoles]

Custom plugins are can currently only be configured by the built in properties, or by environment variables.

A mechanism is required whereby they can be passed free form options e.g as a Java properties object.

[hcoles]

All tool classpath plugins now accept a Properties object to their factory method. Custom properties can now be set within a nested configuration section of the pitest config via maven.

<plugin>
    <groupId>org.pitest</groupId>
    <artifactId>pitest-maven</artifactId>
    <version>LATEST</version>
    <configuration>
        <targetClasses>
            <param>com.your.package.root.want.to.mutate*</param>
        </targetClasses>
        <configuration>
           <foo>valueneededbyplugin</foo>
        </configuration>
    </configuration>
</plugin>

Open questions

1. Is there any issue with also allowing this for client classpath plugins? (probably not)
2. Is "configuration" a good choice of name for the nested tag?
3. How should these properties be set via ant/commandline/gradle?

@szpak Any thoughts/preferences for how this is handled? Is the gradle plugin still implemented in terms of the command line tool?

[StefanPenndorf]

Let me comment on your open questions:

1. depending on the way configuration is sent to the client (as system properties?) and the amount of configuration there was a problem with older windows systems. Don't know if Windows 7 and above suffer the same limitations but surefire users had problems with too long classpaths on windows systems.
2. Maybe the tag could be named <pluginConfiguration> to emphasize, that this tag contains configuration for plugins only and to avoid confusion with maven's <configuration> Tag
3. for command line I would suggest:

java -cp <your classpath including pit jar and dependencies> \
    org.pitest.mutationtest.commandline.MutationCoverageReport \
    --reportDir  \
    --targetClasses com.your.package.tobemutated* \
    --targetTests com.your.packge.*
    --sourceDirs  \
    --pluginConfiguration "key1=value" \
    --pluginConfiguration "key2=value" \

where the first = will be the separator for key and value (thus = may not be used in configuration property keys)

[hcoles]

@KyleRogers

Configuration would most likely be serialised as part of the existing SlaveArguments class which shouldn't cause any OS specific problems.

pluginConfiguration is certainly a better name. I was toying with the idea of also using for non plugin configuration (given the pain involved in adding a new parameter to all the various build integrations), but this is probably a bad idea.

Your suggests for 3) sounds reasonable. I'd be kean to get @szpak input as it may affect the gradle plugin.

[szpak]

The Gradle plugin under the hood still calls command line PIT, so it would be best (also for the Ant plugin) to allow to configure custom plugins with a command line tool.

The proposed configuration looks ok for me. Assuming that plugin configuration elements are in fact a Properties object the most suitable would be probably to use Groovy map syntax in the Gradle configuration:

pitest {
    pluginConfiguration = [key1: "value1", key2: "value2"]
}

As a custom plugin author could encode lists or other data structures inside the value part it would not be further validated in the Gradle part, only passed as is.

One remark. In the call example proposed by @KyleRogers there is key/value pairs are quoted. Other PIT parameters (like classpath) handles spaces internally. Maybe to keep it consistent pluginConfiguration should behave in a similar way?

[hcoles]

Easiest syntax to support using JOptSimple was

-pluginConfiguration=foo=1 -pluginConfiguration=bar=2

So almost as suggested by @KyleRogers, but without quoting.

Does anyone see any major issues with this?

[szpak]

Btw, is there a recommended name convention for plugin configuration parameters? A plugin name prefix? Fully qualified plugin name prefix? To reduce a chance to make conflicts.

[hcoles]

@szpak I'd suggest pick a simple name for the plugin and use that as a prefix.

[hcoles]

Closing a this functionality now provided by feature strings.