The Gradle team is excited to announce Gradle 7.2-rc-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
Switch your build to use Gradle 7.2-rc-2 by updating your wrapper:
./gradlew wrapper --gradle-version=7.2-rc-2
See the Gradle 7.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 7.2-rc-2.
For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.
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.
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.
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 abbreviationThe 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 is a feature preview that provides a convenient API for referencing dependencies and their versions.
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.
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)
}
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.
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.
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.
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.
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.
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.
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.