Gradle Release Notes

Version 7.2

The Gradle team is excited to announce Gradle 7.2.

This release adds several usability improvements, such as toolchain support for Scala projects, and improves build cache hits between operating systems.

There are also changes to make the remote HTTP build cache more resilient when encountering problems and several bug fixes .

We would like to thank the following community members for their contributions to this release of Gradle:

Ned Twigg, Oliver Kopp, Björn Kautler, naftalmm, Peter Runge, Konstantin Gribov, Zoroark, Stefan Oehme, Martin Kealey, KotlinIsland, Herbert von Broeuschmeul

Table Of Contents

Upgrade instructions

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

./gradlew wrapper --gradle-version=7.2

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

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

New features and usability improvements

Java toolchain support for Scala projects

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.

With this release, toolchain support has been added to the Scala plugin.

Preserving escape sequences when copying files

Previously, it was impossible to prevent Gradle from expanding escape sequences in a copied file when a Copy task also used expand(Map). The default behavior is to convert each escape sequence into the corresponding character in the destination file. For example, the literal string \t becomes a tab character. This might be undesirable when escape sequences in processed files should be preserved as-is.

This release adds Copy.expand(Map,Action) that allows you to disable the automatic conversion of escape sequences.

processResources {
    expand([myProp: "myValue"]) {
        // Do not replace \n or \t with characters
        escapeBackslash = true
    }
}

This method is available to all tasks and specs of type ContentFilterable.

Improved credentials handling for HTTP header-based authentication

Like for password credentials and AWS credentials for repositories, Gradle now looks for credentials for repositories that use HTTP header-based authentication in Gradle properties.

If the name of your project's repository is mySecureRepository, Gradle will search for properties with the names mySecureRepositoryAuthHeaderName and mySecureRepositoryAuthHeaderValue once you've configured the repository to use HttpHeaderCredentials:

repositories {
    maven {
        name = 'mySecureRepository'
        credentials(HttpHeaderCredentials)
        // url = uri(<<some repository url>>)
    }
}

dependencies and dependencyInsight support configuration name abbreviation

The dependencies task and depedencyInsight task reports can be used to list the dependencies used by your project and to identify why a particular version of a dependency was selected.

When using those reports from the command line and selecting a configuration using the --configuration parameter, you can now use an abbreviated camelCase notation in the same way as subproject and task names.

For example, the command-line gradle dependencies --configuration tRC can be used instead of gradle dependencies --configuration testRuntimeClasspath as long as the abbreviation tRC is unambiguous.

Version catalog improvements

Version catalog is a feature preview that provides a convenient API for referencing dependencies and their versions.

Declaring sub-accessors

In previous Gradle releases, it wasn't possible to declare a version catalog where an alias would also contain sub-aliases. For example, it wasn't possible to declare both an alias jackson and jackson.xml, you would have had to create aliases jackson.core and jackson.xml.

This limitation is now lifted.

Declaring plugin versions

Version catalogs already supported declaring versions of your libraries, but they were not accessible to the plugins and buildscript blocks. This limitation is now lifted, and it's possible to declare plugins, for example in the TOML file:

[versions]
jmh = "0.6.5"
[plugins]
jmh = { id = "me.champeau.jmh", version.ref="jmh" }

which allows using them in the plugins block like this:

plugins {
    alias(libs.plugins.jmh)
}

Performance improvements

More cache hits between operating systems

For up-to-date checks and the build cache, Gradle needs to determine if two directory structures contain the same contents. When line endings in text files differ (e.g. when checking out source code on different operating systems) this can appear like the inputs of a task are different, even though the task may not actually produce different outputs. This difference can cause tasks to re-execute unnecessarily, producing identical outputs that could otherwise have been retrieved from the build cache.

A new annotation has been introduced that allows task authors to specify that an input should not be sensitive to differences in line endings. Inputs annotated with @InputFiles, @InputDirectory or @Classpath can additionally be annotated with @NormalizeLineEndings to specify that line endings in text files should be normalized during build cache and up-to-date checks so that files that only differ by line endings will be considered identical. Binary files, on the other hand, will not be affected by this annotation.

abstract class MyTask extends DefaultTask {
    @InputFiles
    @PathSensitive(PathSensitivity.RELATIVE)
    @NormalizeLineEndings
    ConfigurableFileCollection getInputFiles();
}

The JavaCompile task has been updated to normalize line endings in source files when doing up-to-date checks and build cache key calculations.

See the User manual for more information.

Configuration cache support for Groovy and Scala projects

Projects that are written in Groovy or Scala can enable the experimental configuration cache without generating errors from the built-in groovy and scala plugins. Configuration caching is a feature that reduces build times by caching the result of the configuration phase and reusing the result for subsequent builds.

See the full set of supported plugins.

Remote build cache reliability improvements

The Gradle build cache is a cache mechanism that aims to save time by reusing outputs produced by other builds. A remote build cache works by storing build outputs and allowing builds to fetch these outputs from the cache when it is determined that inputs have not changed, avoiding the expensive work of regenerating them.

This release improves the reliability of interactions with a remote build cache.

Automatic retry of uploads on temporary network error

Previously, only load (i.e. GET) requests that failed during request transmission would be automatically retried. Now, store (i.e. PUT) requests are also retried.

This prevents temporary problems, such as connection drops, read or write timeouts, or low-level network failures, to cause cache operations to fail and disable the remote cache for the remainder of the build.

Requests will be retried up to 3 times. If the problem persists, the cache operation will fail and the remote cache will be disabled for the remainder of the build.

Follow redirects by default

Redirect responses are now followed by default with no additional configuration needed.

This can be leveraged to gracefully migrate to new cache locations, utilize some form of request signing to read to and write from other systems, or reroute requests from certain users or geographies to other locations.

For more information on the effect of different types of redirects, consult the User manual.

Use Expect-Continue to avoid redundant uploads

It is now possible to opt-in to the use of Expect-Continue for upload requests.

This is useful when build cache upload requests are regularly rejected or redirected by the server, as it avoids the overhead of transmitting the large file just to have it rejected or redirected.

Consult the User manual for more on the use of expect-continue.

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 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.