Support for identifying the base project directory

[hcoles]

Hi @szpak

I'm hoping to add some functionality to pitest that depends on being able to identify the base directory of a project. From some quick experiments, I don't believe its possible to do this from within pitest itself for a multi module gradle build (excpect by walking directories on the file system).

I'm therefore proposing adding a new parameter to be passed to pitest 1.7.5 onwards

https://github.com/hcoles/pitest/pull/999

It should be set to the root directory of a project. I assume this is easy to identify from within the gradle plugin?

[szpak]

There's project.rootProject which usually should be a good candidate. However, for monorepos and maybe the Android projects it might be tricky and in the aggregate support we decided to put the aggregated report files in the project where the aggregate report plugin was applied (and aggregating reports from its subprojects). Unfortunately, that aggregate plugin is completely optional and the main PIT plugiin knows nothing of it.

The key question is what will it be used for? Just in the context of aggregation?

[hcoles]

The initial use case is support for a .pitest directory at the root of the project to store config for all projects within it. It wouldn't be relevent for aggregation.

[szpak]

I could use the rootProject directory, but allow users to override it - for the corner cases.

I will also probably need a generic mechanism to decide which parameters which be passed to which PIT version (vide --testPlugin).

Btw, would that configuration affect the way how the Gradle plugin configures PIT?

[hcoles]

The idea of the .pitest directory is to provide config without having to update each of the build integrations. The initial thinking is to use it for things best expressed in a file, rather than for individual values.

The immediate use case is licence files for the Arcmutate commercial extensions, but I'm also hoping to release a plugin in the next few weeks that allows sections of the code to be marked as "do not mutate" based on a simple expression language.

I guess gradle's caching mechanism will need to be aware of files in there.

[szpak]

(In the future) The configuration file could be treated as an input for Gradle configuration. However, as the Gradle configuration is more versatile (e.g. a dynamic Groovy/Kotlin expression execution), the Gradle plugin would rather generate the configuration file, based on its own configuration (and generic settings in Gradle - e.g. number and location of the subprojects). In that case, we could probably limit the number of parameters passed to PIT executable (similarly to additionalClasspathFile).