The Gradle team is excited to announce Gradle 8.9-rc-1.
This release improves error and warning reporting for variant issues during dependency resolution. It also exposes structural details of Java compilation errors for IDE integrators, making it easier to analyze and resolve issues.
Additionally, this release includes the ability to display more detailed information about JVMs used by Gradle, as well as other minor improvements.
We would like to thank the following community members for their contributions to this release of Gradle: /dev/mataha, Alex-Vol-Amz, Andrew Quinney, Andrey Mischenko, Björn Kautler, dancer13, Danish Nawab, Endeavour233, Gediminas Rimša, gotovsky, Jay Wei, Jeff, Madalin Valceleanu, markslater, Mel Arthurs, Michael, Nils Brugger, Ole Osterhagen, Piotr Kubowicz, Róbert Papp, Sebastian Davids, Sebastian Schuberth, Stefan Oehme, Stefanos Koutsouflakis, Taeik Lim, Tianyi Tao, Tim Nielens, наб
Be sure to check out the public roadmap for insight into what's planned for future releases.
Switch your build to use Gradle 8.9-rc-1 by updating the Wrapper in your project:
./gradlew wrapper --gradle-version=8.9-rc-1
See the Gradle 8.x upgrade guide to learn about deprecations, breaking changes, and other considerations when upgrading to Gradle 8.9-rc-1.
For Java, Groovy, Kotlin, and Android compatibility, see the full compatibility notes.
Gradle provides a rich set of error and warning messages to help you understand and resolve problems in your build. This release makes it easier to deal with dependency management issues and configuration cache misses.
Gradle provides a powerful dependency management engine that is variant-aware. That means every dependency can have multiple variants (for example, for different Java versions) with separate transitive dependencies. This release significantly improves error reporting around dependency variants, continuing to address requests from a highly voted issue.
When Gradle attempts to resolve a dependency and finds multiple variants available, all of which define attributes that would satisfy the resolution request, the resolution fails with a variant ambiguity error.
A common scenario is that all these variants contain only a single, unrequested attribute with distinct values. The addition of this attribute to the resolution request would resolve the ambiguity. This is almost always the desired solution to this problem, but the previous generic error message did not provide proper guidance in this regard.
The new message explicitly suggests adding this missing attribute if such an attribute exists:
> Could not resolve all files for configuration ':consumer'.
> Could not resolve com.squareup.okhttp3:okhttp:4.4.0.
Required by:
project :
> The consumer was configured to find attribute 'org.gradle.category' with value 'documentation'. There are several available matching variants of com.squareup.okhttp3:okhttp:4.4.0
The only attribute distinguishing these variants is 'org.gradle.docstype'. Add this attribute to the consumer's configuration to resolve the ambiguity:
- Value: 'javadoc' selects variant: 'javadocElements'
- Value: 'sources' selects variant: 'sourcesElements'
- Value: 'other' selects variant: 'additionalDocs'
The full list of variants and attributes is now omitted to make the message clearer. Instead, the message also adds a suggestion to run the dependencyInsight task to view the full list if needed:
* Try:
Use the dependencyInsight report with the --all-variants option to view all variants of the ambiguous dependency. This report is described at https://docs.gradle.org/8.9-rc-1/userguide/viewing_debugging_dependencies.html#sec:identifying_reason_dependency_selection.
If a dependency on a project that declares no variants is requested, dependency resolution will fail. This can happen when depending on a project that does not apply any JVM plugins. A new error message makes this clear:
> No matching variant of project :producer was found. The consumer was configured to find attribute 'color' with value 'green' but:
- No variants exist.
Previously, the error message was misleading, as it mentioned that none of the variants had attributes:
> No matching variant of project :producer was found. The consumer was configured to find attribute 'color' with value 'green' but:
- None of the variants have attributes.
While technically true, this did not emphasize the more important fact that no available variants were found.
Starting with this release, when the configuration cache cannot be reused, the console output provides more detailed information on file changes:
> Calculating task graph as configuration cache cannot be reused because file '.../some-file.txt' has been removed.
or
> Calculating task graph as configuration cache cannot be reused because file '.../some-file.txt' has been replaced by a directory.
Before this release, the console output provided a generic message. The message was shown even if the file content was not changed, but the file itself was removed or replaced with a directory:
> Calculating task graph as configuration cache cannot be reused because file '.../some-file.txt' has changed.
Gradle is integrated into many IDEs using the Tooling API. The following improvements are for IDE integrators.
Gradle now collects and manages problems through the Problems API. This means IDEs and other Tooling API clients can access precise and detailed information about any issues that arise during the build process.
Several Gradle components leverage this new API, including deprecation, task validation, and the dependency version catalog. In this release, the Java compiler is also integrated into this infrastructure.
This integration allows popular IDEs like IntelliJ IDEA and Visual Studio Code to provide a seamless and accurate visual representation of Java compilation issues, eliminating the need to parse text output from the compiler. Eclipse Buildship will include this in its upcoming release.
Before this release, running gradle --version displayed the JVM used to launch Gradle, but this JVM did not execute any build logic. Instead, Gradle started a Daemon that actually ran the build. Then, Gradle 8.8 introduced a feature that allowed users to configure the JVM used to run the Gradle Daemon.
In this release, users can view information about the JVM used for both the Daemon (which executes the build process) and the Launcher JVM (which initiates the Gradle build process) from the command line.
Running gradle --version provides a short output that highlights the potentially different JVM versions used by the Launcher and the Daemon:
[...]
Launcher JVM: 11.0.23 (Eclipse Adoptium 11.0.23+9)
Daemon JVM: /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home (no JDK specified, using current Java home)
This includes information about how Gradle chose the JVM, including the org.gradle.java.home system property and the incubating Daemon JVM criteria.
More details can be seen by running the buildEnvironment task:
Daemon JVM: Eclipse Temurin JDK 11.0.23+9
| Location: /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
| Language Version: 11
| Vendor: Eclipse Temurin
| Architecture: aarch64
| Is JDK: true
The build init plugin will now ask the user to confirm before proceeding if there are any files in the project directory, including Gradle settings.gradle(.kts) and build.gradle(.kts) files.
This change is intended to prevent accidental overwriting of existing files in the project directory.
Build init now has a new --overwrite option, which allows users to bypass this confirmation message. This can be used if initialization is canceled or fails, and the user wants to re-run the init task without being prompted to confirm.
If the user declines to overwrite files that exist, or if the --no-overwrite option is provided, initialization will fail with the message: Aborting build initialization due to existing files in the project directory: <PATH>
The exception to this behavior is when Gradle detects an existing Maven build via the presence of a pom.xml file - these builds will be converted to Gradle builds without prompting.
Test tasks using the TestNG framework now support configuring the suiteThreadPoolSize on the TestNGOptions.
More information about this option is available in the TestNG documentation.
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.