The Gradle team is excited to announce Gradle 7.4-rc-2.
This release makes it easier to create a single test report or JaCoCo code coverage report across several projects. This release also includes several usability improvements, such as marking additional test source directories as tests in IDEA and better support for plugin version declarations in subprojects.
Java toolchain support has been updated to reflect the migration of AdoptOpenJDK to Adoptium.
There are changes to make adopting the experimental configuration cache easier, along with several bug fixes and other changes.
The build services and version catalogs features have been promoted to stable.
We would like to thank the following community members for their contributions to this release of Gradle:
Michael Bailey, Jochen Schalanda, Jendrik Johannes, Roberto Perez Alcolea, Konstantin Gribov, Per Lundberg, Piyush Mor, Róbert Papp, Piyush Mor, Ned Twigg, Nikolas Grottendieck, Lars Grefer, Patrick Pichler, Marcin Mielnicki, Marcono1234, Dima Merkurev. Matthew Haughton
Switch your build to use Gradle 7.4-rc-2 by updating your wrapper:
./gradlew wrapper --gradle-version=7.4-rc-2
See the Gradle 7.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 7.4-rc-2.
For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.
By default, Gradle produces a separate HTML test report for every test task in each project. Previously, it was difficult to combine those reports across multiple projects in a safe and convenient way.
This release adds the new test-report-aggregation plugin to make it easy to aggregate test results from multiple projects into a single HTML report. This plugin uses test suites registered with the jvm-test-suite plugin.
When this plugin is applied to a Java project, Gradle will automatically create an aggregated test report for each test suite with test results from a compatible test suite in every project that the Java project depends on. See the sample in the user manual.
If you want more control over the set of projects that are included in the aggregated report or which test suites are used, see another sample that requires you to provide this configuration in the user manual.
Gradle comes with a JaCoCo code coverage plugin that produces a coverage report for the built-in test task. Previously, it was difficult to combine such reports across multiple projects in a safe and convenient way.
This release adds the new jacoco-report-aggregation plugin to make it easy to aggregate code coverage from multiple projects into a single report. This plugin uses test suites registered with the jvm-test-suite plugin.
When this plugin is applied to a Java project, Gradle will automatically create an aggregated code coverage report for each test suite with code coverage data from a compatible test suite in every project that the Java project depends on. See the sample in the user manual.
If you want more control over the set of projects that are included in the aggregated report or which test suites are used, see another sample that requires you to provide this configuration in the user manual.
The JVM Test Suite Plugin makes it easier to create additional sets of tests in a Java project.
The IntelliJ IDEA Plugin plugin will now automatically mark all source directories used by a JVM Test Suite as test source directories within the IDE.
The Eclipse plugin will be updated in a future version of Gradle.
This change does not affect additional test source directories created in Android projects that will still need to be manually configured to be considered test directories. These test sources are not created using JVM test suites.
repositories {} in Kotlin DSLStarting with this version of Gradle, Kotlin DSL generates type-safe model accessors for custom extensions added to the repositories {} block. Custom extensions now have full content assist in the IDE.
For instance, the asciidoctorj-gems-plugin plugin adds a custom extension. You can now use this succinct syntax:
repositories {
ruby {
gems()
}
}
In previous releases, you were required to use withGroovyBuilder:
repositories {
withGroovyBuilder {
"ruby" {
"gems"()
}
}
}
or directly rely on the type of the extension:
repositories {
this as ExtensionAware
configure<com.github.jrubygradle.api.core.RepositoryHandlerExtension> {
gems()
}
}
Dependency verification allows Gradle to verify the checksums and signatures of the plugins and dependencies that are used by the build of your project to improve supply chain security.
With this release, the generation of the dependency verification file has been improved to produce stable output. This means that Gradle will always produce the same output if the build configuration and the verification file did not change.
This allows the the verification metadata generation feature to be used as a convenient update strategy. This is now a recommended way to update the dependency verification files.
See the documentation for more details.
The plugins DSL provides a succinct and convenient way to declare plugin dependencies.
Previously, it was not possible to declare a plugin with a version in a subproject when the parent project also declared the same plugin. Now, this is allowed when Gradle can track the version of the plugin (currently when using included build plugins or externally resolved plugins), and the version of the plugin in both are the same.
This change was required to allow the use of dependency catalog plugin aliases in both a parent and subproject's plugins {}.
Java toolchains provide an easy way to declare which Java version your project should be built with. By default, Gradle will detect installed JDKs or automatically download new toolchain versions.
Following the migration of AdoptOpenJDK to Eclipse Adoptium, a number of changes have been made for toolchains:
ADOPTIUM and IBM_SEMERU are now recognized as vendors,ADOPTOPENJDK as a vendor and having it trigger auto-provisioning will emit a deprecation warning.See the documentation for details.
The configuration cache improves build time by caching the result of the configuration phase and reusing this for subsequent builds.
Previously, Gradle required build and plugin authors to use specific APIs to read external values such as environment variables, system properties and Gradle properties in order to take these values into consideration as configuration cache inputs. When one of those values changed, Gradle would re-execute the configuration phase of the build and create a new cache entry. Gradle also required marking external values used at configuration time with an explicit opt-in Provider.forUseAtConfigurationTime() API.
This release makes it easier to adopt configuration cache by relaxing these requirements. Provider.forUseAtConfigurationTime() has been deprecated and external values can be read using standard Java and Gradle APIs. Environment variables, system properties and Gradle properties used at configuration time are automatically detected without requiring build or plugin authors to migrate to Gradle specific APIs. In case any of those inputs change, the configuration cache is invalidated automatically. Moreover, the detected configuration inputs are now presented in the configuration-cache HTML report to make it easier to investigate unexpected configuration cache misses.
See the corresponding section of the upgrade guide for details.
The configuration cache works by caching the entire task graph for each set of requested tasks.
Prior to this release, all tasks used by the project needed to be compatible with configuration cache before the configuration cache could be enabled.
It is now possible to declare that a particular task is not compatible with the configuration cache. Gradle will disable the configuration cache automatically whenever an incompatible task is scheduled to run. This makes it possible to enable the configuration cache without having to first migrate all tasks to be compatible. Builds will still benefit from the configuration cache when only compatible tasks are executed. This enables more gradual adoption of the configuration cache.
Check the user manual for more details.
The Gradle daemon can be started in a debug mode that allows you to connect a debugger to troubleshoot build scripts or plugin code execution. By default, Gradle assumes a particular set of debugging options.
In this release, additional options have been added to specify the port, server mode, and suspend mode for the Gradle daemon. This is useful when the default options are not sufficient to connect to the Gradle daemon to debug build scripts or plugin code.
This does not affect the debugging options used with --debug-jvm when used with Test or JavaExec tasks.
See the documentation for details.
This improvement was contributed by Marcin Mielnicki.
Precompiled plugins are plugins written in either Groovy or Kotlin DSLs. They are used to easily share build logic between projects using a DSL language and without the need to write a full plugin class.
In previous versions, it was possible to name a precompiled plugin with a name that conflicted with any core plugin id. Since core plugins take precedence over other plugins this caused the precompiled plugin to be silently ignored.
With this release, a name conflict between a precompiled plugin and a core plugin causes an error.
See the user manual for precompiled plugins for more information.
Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility. See the User Manual section on the “Feature Lifecycle” for more information.
The following are the features that have been promoted in this Gradle release.
Shared build services is promoted to a stable feature.
Version catalogs is promoted to a stable feature.
Some CI hosting providers like Azure automatically close idle connections after a certain period of time.
This caused problems with connections to the Gradle Build Cache which could have an open connection for the entire execution of the build.
This release of Gradle fixes this issue by automatically closing idle connections after 3 min by default.
Known issues are problems that were discovered post release that are directly related to changes made in this release.
We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.
If you find a problem with this release, please file a bug on GitHub Issues adhering to our issue guidelines. If you're not sure you're encountering a bug, please use the forum.
We hope you will build happiness with Gradle, and we look forward to your feedback via Twitter or on GitHub.