The Gradle team is excited to announce Gradle 7.6.3.
This is the third patch release for Gradle 7.6.
This release addresses two security vulnerabilities:
It also fixes the following issues:
Issues fixed in the second patch release:
Issues fixed in the first patch release:
.gradle/jdksWe recommend users upgrade to 7.6.3 instead of 7.6.
This release includes building and running code with Java 19, a flag to rerun tasks individually, a new strongly-typed dependencies block for JVM test suites, and a pluggable system for Java Toolchains provisioning.
As always there are also performance improvements like enhancements to the configuration cache and incremental compilation.
We would like to thank the following community members for their contributions to this release of Gradle: altrisi, aSemy, Ashwin Pankaj, Aurimas, BJ Hargrave, Björn Kautler, Bradley Turek, Craig Andrews, Daniel Lin, David Morris, Edmund Mok, Frosty-J, Gabriel Feo, Ivan Gavrilovic, Jendrik Johannes, John, Joseph Woolf, Karl-Michael Schindler, Konstantin Gribov, Leonardo Brondani Schenkel, Martin d'Anjou, Michael Bailey, Pete Bentley, Rob Bavey, Sam Snyder, sll552, teawithbrownsugar, Thomas Broadley, urdak, Varun Sharma, Xin Wang
Switch your build to use Gradle 7.6.3 by updating your wrapper:
./gradlew wrapper --gradle-version=7.6.3
See the Gradle 7.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 7.6.3.
For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.
Gradle 7.6 supports compiling, testing and running on Java 19.
dependencies block for JVM test suitesThe JVM test suite dependencies block now uses a strongly-typed API. This makes the build logic cleaner and improves assistance in the IDEs, especially with the Kotlin DSL.
Previously, the JVM test suite dependencies block only accepted dependencies of type Object.
testing {
suites {
val test by getting(JvmTestSuite::class) {
useJUnitJupiter()
dependencies {
implementation(project(":foo")) {
// Receiver (this) is of type Dependency
// To access ProjectDependency
// methods, smart-cast:
this as ProjectDependency
// Now available as a ProjectDependency
println(dependencyProject)
}
}
}
}
}
Now, each notation provides its Dependency subtype:
testing {
suites {
val test by getting(JvmTestSuite::class) {
useJUnitJupiter()
dependencies {
implementation(project(":foo")) {
// `this` already of type ProjectDependency
println(dependencyProject)
}
}
}
}
}
For example, using a String provides an ExternalModuleDependency. Using a FileCollection provides a FileCollectionDependency. This allows Java and Kotlin to properly configure all types of dependencies and improves IDE support for the Groovy DSL.
In addition, the Kotlin DSL now supports named arguments for external dependencies in this block:
testing {
suites {
"test"(JvmTestSuite::class) {
useJUnitJupiter()
dependencies {
implementation(module(group = "com.google.guava",
name = "guava",
version = "31.1-jre"))
}
}
}
}
For more information about the test suite dependencies block, see Differences Between Test Suite and Top-Level Dependencies.
Starting in Gradle 7.6, Gradle can download JVM toolchains from arbitrary repositories. By default, Gradle downloads toolchains from Adoptium/AdoptOpenJDK. You can now override the default providers with repositories of your choice using a toolchain resolver plugin.
For example, the following uses custom plugins that provide AzulResolver and AdoptiumResolver to add custom toolchains for Adoptium and Azul:
toolchainManagement {
jvm {
javaRepositories {
repository("azul") {
resolverClass.set(AzulResolver::class.java)
credentials {
username = "user"
password = "password"
}
authentication {
create<DigestAuthentication>("digest")
}
}
repository("adoptium") {
resolverClass.set(AdoptiumResolver::class.java)
}
}
}
}
For more information about using custom toolchain resolvers, see the Toolchain Download Repositories documentation. For more information about writing custom toolchain resolvers, see the Toolchain Resolver Plugins documentation.
Gradle supports Java incremental compilation by default and Groovy incremental compilation as an opt-in experimental feature.
In previous versions, a compilation failure caused the next compilation to perform a full recompile. Starting in Gradle 7.6, Java and Groovy incremental compilation can work even after a failure.
This feature is enabled by default when incremental compilation is enabled. The feature can be disabled with the incrementalAfterFailure compile option.
You can run a Java test or application child process with debugging options to accept debugger client connections over the network. If the debugging options only specify a port, but not a host address, the set of accepted connections depends on your version of Java:
This release adds a new property to JavaDebugOptions: host. This allows you to specify the debugger host address along with the port.
Similarly, the new Gradle property org.gradle.debug.host now enables running the Gradle process with the debugger server accepting connections via network on Java 9 and above.
On Java 9 and above, use the special host address value * to make the debugger server listen on all network interfaces. Otherwise, use the address of one of the machine's network interfaces.
init Maven conversions from implementation to apiThe init task now adds compile-time Maven dependencies to Gradle's api configuration when converting a Maven project. This sharply reduces the number of compilation errors. It is still recommended to use implementation where possible.
For more information about Maven conversions, see the Build Init Plugin.
rerunAll tasks can now use the --rerun option. This option works like --rerun-tasks, except --rerun only affects a single task. For example, you can force tests to ignore up-to-date checks like this:
gradle test --rerun
For more information about the rerun option, see Built-in Task Options.
init🐣 This feature is incubating.
When generating builds with the init task and opting in to incubating features, Gradle now places convention plugins under the build-logic directory instead of in buildSrc.
Convention plugins are Gradle’s recommended way of organizing build logic where you can compose custom build logic by applying and configuring both core and external plugins.
For more information about convention plugins, see Convention Plugins.
It is now possible to configure the network timeout for downloading Gradle wrapper files. The default value is 10000ms and can be changed in several ways:
From the command line:
$ ./gradlew wrapper --network-timeout=30000
In your build scripts or convention plugins:
tasks.wrapper {
networkTimeout.set(30000)
}
Or in gradle/wrapper/gradle-wrapper.properties:
networkTimeout=30000
For more information about the Gradle wrapper, see Gradle Wrapper.
You can now provide a reason message when conditionally disabling a task using the Task.onlyIf predicate:
tasks.register("slowBenchmark") {
onlyIf("slow benchmarks not enabled") {
false
}
}
Gradle outputs reason messages at log level INFO. To output reason messages to the console, use the --info or --debug log levels.
resolvableConfigurations reportsAttribute disambiguation rules control the variant of a dependency selected by Gradle when:
Attribute disambiguation rules select a single matching dependency variant in such cases. The resolvableConfigurations reporting task now prints the order of these rules:
$ ./gradlew resolvableConfigurations
--------------------------------------------------
Disambiguation Rules
--------------------------------------------------
The following Attributes have disambiguation rules defined.
- flavor
- org.gradle.category (1)
- org.gradle.dependency.bundling (5)
- org.gradle.jvm.environment (6)
- org.gradle.jvm.version (3)
- org.gradle.libraryelements (4)
- org.gradle.plugin.api-version
- org.gradle.usage (2)
(#): Attribute disambiguation precedence
For more information, see Attribute Disambiguation Rules.
The configuration cache improves build time by caching the result of the configuration phase and reusing this for subsequent builds.
In previous Gradle versions, it was possible to leave a configuration cache entry in a permanently broken state after a dependency resolution failure. Following builds would simply reproduce the failure without any attempt to recover from it.
Starting with Gradle 7.6, this is no longer the case. Gradle recovers from dependency resolution failures in exactly the same way whether the configuration cache is enabled or not.
The dependencies, buildEnvironment, projects and properties tasks are now compatible with the configuration cache.
The Maven Publish Plugin is now compatible with the configuration cache.
Note that when using credentials, the configuration cache requires safe credential containers.
--offline optionGradle now stores configuration caches for online and offline modes separately. This change supports builds and plugins that need to behave differently during configuration depending on whether the --offline option is in effect.
For more information, see the --offline CLI option.
IntegerYou can now pass integer task options declared as Property<Integer> from the command line.
For example, the following task option:
@Option(option = "integer-option", description = "description")
public abstract Property<Integer> getIntegerOption();
can be passed from the command line as follows:
gradle myCustomTask --integer-option=123
These improvements are for IDE integrators and are not directly for end-users until their specific IDE implements the integration.
Gradle 7.6 introduces new failure types for the Failure interface returned by FailureResult.getFailures(): TestAssertionFailure and TestFrameworkFailure. IDEs can now distinguish between assertion and framework failures using progress event listeners. For test frameworks that expose expected and actual values, TestAssertionFailure contains those values.
TestLauncher task executionThe TestLauncher interface now allows Tooling API clients to execute any tasks along with the selected tests:
ProjectConnection connection = ...
connection.newTestLauncher()
.withTaskAndTestClasses("integTest", ["org.MyTest"])
.forTasks("startDB")
.run()
TestLauncherThe TestLauncher interface now allows Tooling API clients to select test classes, methods, packages and patterns with a new API.
TestLauncher testLauncher = projectConnection.newTestLauncher();
testLauncher.withTestsFor(spec -> {
spec.forTaskPath(":test")
.includePackage("org.pkg")
.includeClass("com.TestClass")
.includeMethod("com.TestClass")
.includePattern("io.*")
}).run();
Before 7.6, the Tooling API started builds with the system properties from the host JVM. This leaked configuration from the IDE to the build. Starting in Gradle 7.6, LongRunningOperation.withSystemProperties(Map) provides an isolated set of build system properties. For more information, see LongRunningOperation.
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.
This Gradle release promotes the following features to stable:
getTestSources and getTestResourcesgetDestinationDirectory and getTestResultsKnown 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.