Gradle Release Notes

Version 6.2-rc-1

The Gradle team is excited to announce Gradle 6.2-rc-1.

This release adds built-in dependency checksum and signature verification, provides a shareable read-only dependency cache and emits helpful documentation links when you have deprecations in your build.

As always, there are several bug fixes, IDE improvements for Gradle plugin authors and more.

We would like to thank the following community contributors to this release of Gradle:

Stefan Neuhaus, EthanLozano, Pavlos-Petros Tournaris, Márton Braun, Thomas Iguchi, Vladimir Sitnikov, Peter Stöckli, Sebastian Schuberth, Frieder Bluemle, ColtonIdle, and Roberto Perez Alcolea.

Table Of Contents

Upgrade Instructions

Switch your build to use Gradle 6.2-rc-1 by updating your wrapper:

./gradlew wrapper --gradle-version=6.2-rc-1

See the Gradle 6.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 6.2-rc-1.

For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.

Dependency verification

Typical projects use a large number of external dependencies which put them at risk of using untrusted code. What if you accidentally introduced malicious code via a transitive dependency? Similarly, what if your build script itself is vulnerable to malicious code execution via a compromised plugin?

In an effort to mitigate the risks, Gradle 6.2 ships with dependency verification. Dependency verification is a major step towards a safer ecosystem by making it possible to verify both the checksums and the signatures of dependencies and plugins used during a build.

By enabling dependency verification, Gradle will:

and therefore dramatically reduce the risks of shipping malicious code to production.

With dependency verification, you maintain an XML file with checksums and optionally also signatures of all external artifacts used in your project, which includes, but is not limited to, all jars (binaries, sources, ...) and plugins. Gradle will immediately fail the build if an artifact is not trusted or missing from the configuration file.

Please refer to the user manual for a complete explanation about how to setup dependency verification.

We would like to give special thanks to Vladimir Sitnikov for his feedback and inspiration. A lot of the work on this feature is, in particular, available to previous versions of Gradle via his Checksum Dependency Plugin.

Shared dependency cache

Improving on relocatable dependency caches introduced in the previous release, Gradle 6.2 now offers the ability to share a dependency cache between multiple Gradle instances.

In the context of ephemeral builds on disposable containers, this makes it possible to have a single shared directory that contains the dependencies required by all builds.

Please refer to the user manual to learn how to setup the shared dependency cache.

Deprecation messages now include links to relevant documentation that can provide more context around the deprecation and explain how to migrate to a new API or avoid the deprecated behavior.

For example:

The compile configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 7.0. Please use the implementation configuration instead. Consult the upgrading guide for further information:

In some terminals, this link will be clickable and take you directly to the documentation.

Declaring exclusive repository content

Gradle lets you declare precisely what a repository contains, which is interesting both for build speed (avoiding pinging redundant repositories) and security (avoiding leaking details to the world about your own projects):

repositories {
   myRepo {
       url ""
       content {
           includeGroup "com.mycompany"

However, this doesn't prevent Gradle from searching artifacts in other repositories, especially if they were declared before. In the example above, if Gradle needs to resolve an artifact com.mycompany:awesome-lib:1.0, it will first search into mavenCentral(), then into your company repository.

Gradle 6.2 provides an exclusive content API which lets you say that if some artifact can be found in one repository, it cannot be found in any other:

repositories {
    exclusiveContent {
       forRepository {
           myRepo {
               url ""
       filter {
           includeGroup "com.mycompany"

Please refer to the user manual for details.

Improvements for Plugin Development

Gradle API source code for plugin developers in IDEs

Plugin authors will now have the sources of the gradleApi(), gradleTestKit() and localGroovy() dependencies attached for navigation in the IDE.

This works out of the box with Eclipse Buildship.

For IntelliJ IDEA, the sources for gradleApi() are only attached when the Gradle wrapper is used with an -all distribution. Sources for gradleTestKit() and localGroovy() are not attached at the moment. This will change once IDEA-231667 is resolved. Then, the sources for all Gradle APIs (gradleApi(), gradleTestKit() and localGroovy()) will be downloaded and attached on-demand regardless of the wrapper in use.

Injectable services available to Settings plugins

Our ExecOperations and FileSystemOperations injectable services are now available to Settings plugins.

Gradle Wrapper Verification GitHub Action

We have created an official GitHub Action that allows your projects on GitHub to automatically verify that the gradle-wrapper.jar in their repository was released by Gradle.

See why this is important and how to apply this action to your project here.

You can still manually verify the gradle-wrapper.jar by following the instructions in our Gradle Wrapper user manual.

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.

Fixed issues

Known issues

Known issues are problems that were discovered post release that are directly related to changes made in this release.

External contributions

We love getting contributions from the Gradle community. For information on contributing, please see

Reporting Problems

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.