The Gradle team is excited to announce Gradle 8.2-rc-1.
Kotlin DSL continues to receive substantial improvements. The new reference documentation makes Kotlin DSL easier to understand. Also, simple property assignment with the = operator introduced to Kotlin DSL in the last release is now enabled by default. Finally, Kotlin DSL is now the default option when generating a new project with the init task.
This release also brings a number of usability improvements including better error messages, automated validation of distribution URL in the wrapper task, progress display for discovery of Java toolchains, more efficient dependency verification and more.
We would like to thank the following community members for their contributions to this release of Gradle: Bruno Didot, Eric Vantillard, esfomeado, Jendrik Johannes, Jonathan Leitschuh, Lee Euije, Stefan Oehme, Todor Dinev, Yanshun Li
Switch your build to use Gradle 8.2-rc-1 by updating your wrapper:
./gradlew wrapper --gradle-version=8.2-rc-1
See the Gradle 7.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 8.2-rc-1.
For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.
Gradle's Kotlin DSL provides an enhanced editing experience in supported IDEs compared to the traditional Groovy DSL — auto-completion, smart content assist, quick access to documentation, navigation to source, and context-aware refactoring.
Kotlin DSL has received substantial improvements in the recent releases, leading to the announcement that Kotlin DSL is Now the Default for New Gradle Builds. This release brings another series of improvements.
A brand new reference documentation for the Gradle Kotlin DSL is now published and versioned alongside the user manual.
You can use the Kotlin DSL reference search functionality to drill through the APIs.
The last release introduced the simpler way to assign values to lazy property types in Kotlin scripts using the = operator instead of the set() method. This new assignment operator is now available by default.
This feature is still incubating. In case of any issues you can opt-out by adding systemProp.org.gradle.unsafe.kotlin.assignment=false to the gradle.properties file.
For more information see Kotlin DSL Primer.
init defaults to the Kotlin DSLStarting with this release, generating a new project with the gradle init command now defaults to using the Kotlin DSL instead of Groovy DSL.
In interactive mode you can choose which DSL to use and the Kotlin one is now listed first:
Select build script DSL:
1: Kotlin
2: Groovy
Enter selection (default: Kotlin) [1..2]
See the build init user manual chapter for more information.
Gradle Kotlin DSL scripts are compiled by Gradle during the configuration phase of your build. Deprecation warnings found by the Kotlin compiler are reported on the console when compiling the scripts.
In order to catch potential issues faster, it is now possible to configure your build to fail on any warning emitted during script compilation by setting the org.gradle.kotlin.dsl.allWarningsAsErrors Gradle property to true:
# gradle.properties
org.gradle.kotlin.dsl.allWarningsAsErrors=true
More details can be found in the dedicated section of the Kotlin DSL user manual chapter.
In the new release, we have taken the first step towards implementing the clean and actionable error reporting item from our public roadmap, by making a number of improvements to the console output in case of build failures.
Suggestions that were previously a part of the error message are now displayed in the * Try section, making them more noticeable. Additionally, the output is streamlined by eliminating unnecessary links to help.gradle.org for recoverable errors, such as compilation failures.
You can review the complete list of these console output enhancements here.
The Gradle Wrapper stores the URL of Gradle distribution in the gradle-wrapper.properties file.
Previously, specifying an invalid URL led to I/O exceptions during the build execution.
Starting from this release, the wrapper task automatically validates the configured distribution URL before writing it to the gradle-wrapper.properties file. This surfaces invalid URLSs early and prevents exceptions at execution time.
More details can be found in the dedicated section of the Gradle Wrapper user manual chapter.
Using Toolchains is a recommended way of specifying Java versions for JVM projects.
Progress is now displayed during Java toolchains discovery.
This can be especially useful during a cold-start of Gradle for users who have environments with a lot of JVM installations in them.
To mitigate the security risks and avoid integrating compromised dependencies in your project, Gradle supports dependency verification.
Exported PGP keys are now stripped to contain only necessary data. This feature can significantly reduce the size of the keyring files.
In addition, the exported keyring is sorted by key id and de-duplicated to ensure a consistent ordering of keys, which minimizes potential conflicts when updating the keyring.
In order to benefit from these changes, users will have to generate again their keyring.
Task options of type boolean, Boolean, and Property<Boolean> now automatically generate an opposite option to make setting the value to false easier in the command-line interface.
This feature lets you conveniently set the Boolean option to false, simply by using the --no- prefix. For example, --no-foo option is generated for the provided option --foo.
See the task options user manual section for more information.
Using gradle init to convert a multimodule Maven build previously required the child submodule projects’ POMs to reference their parent POM using:
<parent>
<artifactId>parent-project</artifactId>
<groupId>com.example</groupId>
<version>1.0</version>
</parent>
Without these backreferences, the conversion process would fail.
The process has been updated to succeed also when the parent element is absent from the submodules.
Using the Configuration API is a fundamental piece of writing Gradle builds. This is a large and multipurpose API that is easy to accidentally misuse. This release of Gradle will provide additional feedback if configurations are used inconsistently.
Certain methods in the Configuration API should only be called when the configuration is in a particular “role” as determined by the isCanBeResolved()/isCanBeConsumed()/isCanBeDeclared() flags. For example, calling shouldResolveConsistentlyWith(Configuration) should only be done on a resolvable Configuration. Calling a method that is not appropriate for a configuration’s current role will now in many cases emit a deprecation warning.
These proper usages are now mentioned on the Configuration type’s javadoc.
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.