classPathFile support (PIT 1.1.11) about gradle-pitest-plugin

[szpak]

Added in 1.1.11.

[FlasH-RUS]

I was unable to make it work out of the box for #276 (i.e. running gradle build on windows machine while having a really long dependency list). Since taskClasspath is still automatically constructed from runtime classpaths of testSourceSets the resulting classpath might still be too long for windows machine even if you are using classPathFile.
My WA was to set classPathFile AND provide a fake testSourceSets while still adding all corresponding dependencies into class path file + adding required task dependencies.
Note that you can't just erase testSourceSet because plugin will still generate an empty classpath argument for a command line runner which in turn results in Pitest's OptionParser to omit mutableCodePaths, which comes next.
Working WA code:

task pitestClassPathFile(dependsOn: testClasses) << {
    StringBuilder classPathFileContents = new StringBuilder()
    sourceSets.test.runtimeClasspath.getFiles().forEach { filePath ->
        classPathFileContents.append(filePath).append('\n')
    }

    def classPathFile = new File("${project.buildDir}/pitestClassPathFile")
    classPathFile.write(classPathFileContents.toString())
}

pitest {
...
    def fakeSourceSet = [
        runtimeClasspath: project.sourceSets.test.output.classesDir,
        name: project.sourceSets.test.name
    ]
    testSourceSets = [ fakeSourceSet ]
    classPathFile = file("${project.buildDir}/pitestClassPathFile")
}

tasks['pitest'].dependsOn pitestClassPathFile

[FlasH-RUS]

Probably the quickest fix would be to just omit classPath command line argument if it's empty and/or if classPathFile is provided.

[szpak]

I was thinking about a similar solution. An additional useClassPathFile boolean property to make the plugin use an automatically created file filled with a classPath and to clear up the classPath parameter passed to PIT.

[szpak]

The Gradle plugin itself doesn't provide a direct way to specify a classpath passed to PIT - it is based on the project configuration. It was my oversight to expose classPathFile directly in the plugin configuration. Created #56.

Thanks @FlasH-RUS for spotting the issue.