1.6.5

This release keeps improving the 1.6.x series by focusing on Gradle 7.x migration for plugin authors. The Groovy upgrade in Gradle 7.0 can cause some headaches if your plugin build has dependencies on Groovy 2.x. Thanks to the Gradle API redistribution project, we already offer versioned dependencies for the Gradle API and Gradle TestKit. However, prior to this version, we relied on the core Gradle plugin to provide the Gradle TestKit dependency. Going forward, we will no longer use gradlePlugin.testSourceSets(...) API and instead produce our own wiring for testing. The functional test plugin will automatically include a dependency to the Gradle TestKit remote dependency matching your API version. If you wish to have a dependency on Gradle TestKit for your unit test, use the following snippet:

test {
    dependencies {
        implementation gradleTestKit('7.4') // use any version
    }
}

Note that gradleTestKit(<version>) is a convenient API that simply resolves to the Maven coordinate. Furthermore, if you use the dev.gradleplugins.gradle-plugin-development plugin, we provide the same convenient API directly on the project dependencies:

plugins {
    id 'dev.gradleplugins.gradle-plugin-development'
    id 'java-library'
}

dependencies {
    implementation gradleTestKit('7.4') // use any version
}

If for some reason, our plugins do not meet your need, you can use the Maven coordinates directly for Gradle API and Gradle TestKit. However, we welcome any improvement recommendations via GitHub issues.

Finally, each test suite now has its own pluginUnderTestMetadata task which Gradle TestKit uses to automatically figure out the classpath to inject inside the child Gradle instance. Note that you can still use pluginUnderTestMetadata configuration available on each test suite to include additional plugin dependencies, useful when your plugins span multiple projects.