Gradle Release Notes

Upgrade Instructions

Switch your build to use Gradle 6.2.1 by updating your wrapper:

./gradlew wrapper --gradle-version=6.2.1

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

NOTE: Gradle 6.2 has had one patch release fixing several issues. We recommend always using the latest patch release.

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 these 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:

• make sure that the dependencies haven't been tampered with (by verifying their checksums)
• ensure the provenance of dependencies and plugins you use (by verifying their signatures)

and therefore 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 set up 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.

• Each container will have access to the shared read-only dependency cache, which avoids redundant downloads between builds.
• This cache can be safely shared between containers without creating separate copies of it.

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

Declaring exclusive repository content

Gradle lets you declare which repositories should be searched for specific dependencies. This can speed up builds by reducing the number of repositories that need to be searched and increases security by not leaking details about your internal projects.

As an example:

repositories {
   mavenCentral()
   myRepo {
       url "https://my-company.com/repo"
       content {
           includeGroup "com.mycompany"
       }
   }

If Gradle needs to resolve the dependency com.mycompany:awesome-lib:1.0, it will first search in the repository Maven Central and then in your company repository. This is unnecessary if com.mycompany dependencies will never be found in Maven Central.

Gradle 6.2 provides an exclusive content API, which lets you convieniently declare that a dependency can be found in one repository and it shouldn't be searched for in any other.

repositories {
    jcenter()
    exclusiveContent {
       forRepository {
           myRepo {
               url "https://my-company.com/repo"
           }
       }
       filter {
           includeGroup "com.mycompany"
       }
    }
}

In this example, when Gradle needs to resolve the dependency com.mycompany:awesome-lib:1.0, it will only search in your company repository. This avoids the unnecessary dependency lookup with Maven Central.

Please refer to the user manual for details.

Deprecation messages link to documentation

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: https://docs.gradle.org/6.2/userguide/upgrading_version_5.html#dependencies

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

Verifying Gradle Wrappers

The Gradle Wrapper is a binary blob of executable code that is checked into millions of GitHub repositories. There are security implications when accepting changes to gradle-wrapper.jar that may not be apparent.

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

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

Improvements for Plugin Development

Injectable services available to Settings plugins

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

Promoted features

Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backward 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 gradle.org/contribute.

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.