Provide a way to configure pitest version AND its dependencies about gradle-pitest-plugin

[hcoles]

This may be an issue with pitest itself, it shouldn't really be pulling in TestNG (or JUnit) as a dependency - it ought to use whatever is defined in the codebase it is examining. These dependencies should be marked as "provided" rather than "compile" - some work might be needed to be able to do this though.

[szpak]

For example, pitest 1.1.0 declares dependency to org.testng:testng:6.1.1 but I want to use (the latest) org.testng:testng:6.8.8 because of reasons.

Have you tried that and it failed? The plugin sets project defined dependencies fist on the classpath passed to PIT, so in case of TestNG your 6.8.8 should be used during the mutation testing phase.

Could you paste (via Gist) a classpath which is displayed when gradle pitest --info command is called?

The plugin creates an invisible pitest configuration at https://github.com/szpak/gradle-pitest-plugin/blob/master/src/main/groovy/info/solidsoft/gradle/pitest/PitestPlugin.groovy#L69, so I believe that simply changing the configuration visibility will allow to override the pitest dependencies.

In the past it was a "normal" configuration, but it then the whole buildscript depends on PIT (and its dependencies) and in addition it was too late at the plugin level to change PIT jar to the version defined in pitestVersion. In current solution only PIT analysis started from the plugin has PIT as a dependency.

Btw, have you tried to define pitest configuration in your buildscript section? I haven't tested that, but the plugin should use it and your explicit dependencies should be stronger than transitive dependencies in PIT.

I am also not sure whether the configuration should be created in the "buildscript" project or in the project being tested.

In the past PIT configuration in Gradle was created in a project space, but it implicated that PIT as a dependency was being resolving during the normal builds

[estekhin]

-cp and --classPath command line options contain both testng 6.8.8 (declared as test dependency for the project) AND testng 6.1.1, but at least 6.8.8 comes before 6.1.1.

The code like

buildscript {
    configurations {
        pitest
    }
    dependencies {
        classpath 'info.solidsoft.gradle.pitest:gradle-pitest-plugin:1.0.0'
        pitest "org.testng:testng:6.8.8"
    }
}

does not work, results in

Could not find method pitest() for arguments [org.testng:testng:6.8.8] on org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler_Decorated@dad5eab.

Adding a "normal" project configuration before applying the plugin, like

configurations {
    pitest
}
apply plugin: 'pitest'
pitest {
    pitestVersion = '1.1.0'
}
dependencies {
    pitest "org.testng:testng:6.8.8"
}

results in exactly the same -cp and --classPath options, with testing 6.8.8 before testing 6.1.1.

In total, it works due to normal testing dependency and the fact that normal project dependency comes before pitest dependency.

What is the problem with making pitest configuration into normal project configuration? It should simply extend from testRuntime, so all test-related classes will be explicitly visible for pitest, but pitest-only dependencies will not be visible in project classes.

[szpak]

In total, it works due to normal testing dependency and the fact that normal project dependency comes before pitest dependency.

Yes, that's something I wrote about in my two previous comments :-). Not beauty, but should work in most cases.

What is the problem with making pitest configuration into normal project configuration?

The first issue is that on every build dependencies for those configurations are resolved even if given task is not executed. You could say it just a few JARs, but building that project on TravisCI or hosted Jenkins extends every build for about several seconds.
The second thing is that IDEs don't handle dependencies from additional configurations well. They are completely ignored in Idea 14 EAP, but AFAIR in Idea 13 they were added to the project libraries what could be confusing in some cases.
I moved PIT to buildscript configuration as it is used only by the plugin.

Even though you cannot create buildscript configuration with the closure (I don't know why) you can use the following code:

buildscript {
    configurations.maybeCreate("pitest")
    pitest 'org.testng:testng:6.8.8'
    (...)

Your explicit TestNG dependency is stronger than old TestNG dependency from PIT and only the new one will be added to the classpath. Would it be a satisfactory solution for you?

Unfortunately it doesn't work with 1.0.0, but I removed (very old) if statement from the code which ignored non empty existing configuration and it will work with 1.1.0. It works for me locally, but before making the release you could test your code with the 1.1.0-SNAPSHOT I have just uploaded do OSS snapshot repository?

[szpak]

I'm closing that issue as 1.1.0 with the modification was released. Feel free to reopen it if you need something more.