Gradle 7.2发布

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

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

50 issues have been fixed in Gradle 7.2.

• [#18035] – Outdated graphics in Gradle Declaring repositories documentation
• [#17816] – GRADLE_CYGPATTERN should be injected into the template adjusted to the built application like GRADLE_OPTS
• [#17815] – Root level files get not path-translated for Cygwin (and msys) in the generated shell scripts
• [#17807] – Linux to Windows path transformation in bash wrapper and start scripts do not work with a cygdrive mount at root
• [#17644] – Provider.zip throws exception on isPresent call when one or both values are missing
• [#17626] – Polish release notes for 7.2
• [#17619] – Kotlin precompiled script plugins fail to compile when plugins declared in inner classes are on the classpath
• [#17592] – Documentation for expected property type for input and output annotations is wrong
• [#17572] – Annotated `package-info.java` breaks incremental compilation for 6.8+
• [#17561] – Gradle erroneously detects missing task dependency between missing output file and input filter containing **
• [#17551] – Gradle’s up-to-date checks do not work on Windows FAT drives
• [#17509] – Confusing behavior of “vendor” selection with Java toolchains
• [#17465] – Upgrade embedded Kotlin to 1.5.x
• [#17433] – Update status of the shutdown/deprecation of JCenter APIs and repository
• [#17423] – Regression in latest nightly around `dependencyInsight` changes
• [#17410] – PMD shows “Error during type resolution” while reported class is available on runtimeClasspath
• [#17383] – Build init plugin is locale sensitive
• [#17340] – Configuration Cache causes ClassNotFoundException when running `tasks` task
• [#17274] – Max open file limits are not considered on MacOs
• [#17273] – Adding custom `PublishArtifact` to `MavenPublication` fails
• [#17227] – Missing Javadoc for Project.relativePath() throwing IllegalArgumentException
• [#17179] – Making a Configuration Copy throws ClassCastException if Type other than DefaultDependencyConstraint among Constraints
• [#17170] – Better error message for typed deps from a TOML file.
• [#17128] – Do not load file-events library in the tooling API client
• [#17086] – Improve the error message about lambdas used as additional action
• [#17075] – Struggling to define KotlinCompileDaemon params with gradle 7.0
• [#16946] – Base plugin overrides project.status and sets it to non-default value
• [#16919] – `ResolvedArtifactResult.getVariant().getCapabilities()` is empty if artifact comes from an `ArtifactCollection`
• [#16555] – Mistakenly recognized 0.7.0+26 as maven incompatible
• [#16409] – Use DisableCachingByDefault annotation on built-in tasks
• [#16141] – Support camelCase shourtcuts for configuration selection in dependencies/dependencyInsinght task
• [#16055] – unix gradle wrapper fails when path contains $ character
• [#15961] – Cache entry for ScalaCompile task does not include compiled classes sometimes
• [#15659] – Gradle Composite build throw IllegalStateException when call `dependencies` task
• [#15405] – GradleConnector#disconnect can trigger undesirable download of a distribution
• [#14563] – TAPI: Offer API to obtain all included builds with nested builds and buildSrc
• [#13461] – Make `scala` plugin support the configuration cache
• [#13460] – Make `groovy` plugin support the configuration cache
• [#12989] – Support creating TAR archives containing files larger than 8 GB
• [#12756] – Ignore `MODIFIED` events for directories on Windows
• [#11651] – Plugin not found on nested composite builds
• [#10808] – Class Cast exception from DefaultProjectDependencyMetadata to ModuleDependencyMetadata when using includeBuild and enforcedPlatform
• [#10751] – Deprecate using Java lambda as task action
• [#10492] – Add option to escape backslash in Copy task expand method
• [#9932] – Receiving S3 input stream abort warnings when using an S3 maven repository
• [#9117] – Measure execution time more strictly
• [#17936] – Could not load the value of field `transformer` of `TransformBackedProvider` bean found in field `file` of `ZipTreeSpec`
• [#17893] – PMD regression in auxclasspath generation in Gradle 7.2-rc-1
• [#17880] – [Configuration cache] Using convention mapping with archiveName on Jar task causes failure
• [#17534] – Provider#zip looses task dependencies

Known issues

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

There are no known issues of Gradle 7.2 at this time.

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.

转自 https://docs.gradle.org/current/release-notes.html