The Gradle team is excited to announce Gradle 8.0-milestone-5.
This release features 1, 2, ... n, and more.
We would like to thank the following community members for their contributions to this release of Gradle:
Andrei Nevedomskii, Björn Kautler, Clara Guerrero, David Marin, Denis Buzmakov, Dmitry Pogrebnoy, Dzmitry Neviadomski, Eliezer Graber, Fedor Ihnatkevich, Gabriel Rodriguez, Guruprasad Bagade, Herbert von Broeuschmeul, Matthew Haughton, Michael Torres, Pankaj Kumar, Ricardo Jiang, Siddardha Bezawada, Stephen Topley, Victor Maldonado, Vinay Potluri, Jeff Gaston, David Morris.
Switch your build to use Gradle 8.0-milestone-5 by updating your wrapper:
./gradlew wrapper --gradle-version=8.0-milestone-5
See the Gradle 7.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 8.0-milestone-5.
For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.
projectInternalView()
dependency for test suites with access to project internalsThe JVM test suite dependencies
block now supports depending on the internal view of the current project at compile-time. Previously it was only possible to depend on the current project's API. This allows test suites to access project internals that are not declared on the api
or compileOnlyApi
configurations. This functionality can be useful when testing internal classes that use dependencies which are not exposed as part of a project's API, like those declared on the implementation
and compileOnly
configurations.
For example, the following snippet uses the new projectInternalView()
API to define a test suite with access to project internals:
testing {
suites {
val unitLikeTestSuite by registering(JvmTestSuite::class) {
useJUnitJupiter()
dependencies {
implementation(projectInternalView())
}
}
}
}
For more information about warning modes, see JVM test suite.
Gradle's Kotlin DSL provides an alternative syntax to the traditional Groovy DSL with an enhanced editing experience in supported IDEs, with superior content assist, refactoring, documentation, and more.
Previously, the Kotlin DSL used Kotlin API level 1.4. Starting with Gradle 8.0, the Kotlin DSL uses Kotlin API level 1.5. This change brings all the improvements made to the Kotlin language and standard library since Kotlin 1.4.0.
For information about breaking and nonbreaking changes in this upgrade, see the upgrading guide.
Previously, the compilation of .gradle.kts
scripts always used Java 8 as the Kotlin JVM target. Starting with Gradle 8.0, it now uses the version of the JVM running the build.
If your team is using e.g. Java 11 to run Gradle, this allows you to use Java 11 librairies and language features in your build scripts.
Note that this doesn't apply to precompiled script plugins which use the configured kotlinDslPluginOptions.jvmTarget
.
This Gradle version introduces an interpreter for declarative plugins {}
blocks in .gradle.kts
scripts. It allows to avoid calling the Kotlin compiler for declarative plugins {}
blocks and is enabled by default.
On a build with declarative plugins {}
blocks, a Gradle invocation that needs to compile all scripts, the interpreter makes the overall build time around 20% faster. As usual, compiled scripts are stored in the build cache and can be reused by other builds.
Here is what is supported in declarative plugins {}
blocks:
plugins {
id("java-library") // <1>
id("com.acme.example") version "1.0 apply false" // <2>
kotlin("jvm") version "1.7.21" // <3>
}
Note that using version catalog aliases for plugins or plugin specification type-safe accessors is not supported by the plugins {}
block interpreter.
Here are examples of unsupported constructs:
plugins {
val v = "2"
id("some") version v // <1>
`java-library` // <2>
alias(libs.plugins.jmh) // <3>
}
In the cases above, Gradle falls back to the Kotlin compiler, providing the same performance as previous Gradle releases.
all
and fail
are now more verboseWarning modes that are supposed to print all warnings were printing only one for each specific warning message.
If there were two warnings with the same message, but originating from different steps of the build process (i.e. different stack traces), only one of them was printed.
Now one gets printed for each combination of message and stack trace.
For more information about warning modes, see Showing or hiding warnings.
The following nodes with dependency verification metadata file verification-metadata.xml
now support a reason
attribute:
trust
xml node under trusted-artifacts
md5
, sha1
, sha256
and sha512
nodes under component
A reason is helpful to provide more details on why an artifact is trusted or why a selected checksum verification is required for an artifact directly in the verification-metadata.xml
.
You can now use the export-keys
flag to export all already trusted keys:
./gradlew --export-keys
There is no longer a need to write verification metadata when exporting trusted keys.
For more information, see Exporting keys.
The CodeNarc project now publishes separate versions for use with Groovy 4. Gradle still currently ships with Groovy 3.
To ensure future compatibility, the CodeNarcPlugin now automatically detects the appropriate version of CodeNarc for the current Groovy runtime.
You can still explicitly specify a CodeNarc version with the toolVersion
property on the CodeNarcExtension.
The PMD and CodeNarc plugins now use the Gradle worker API and JVM toolchains. These tools now perform analysis via an external worker process and therefore their tasks may now run in parallel within one project.
In Java projects, these tools will use the same version of Java required by the project. In other types of projects, they will use the same version of Java that is used by the Gradle daemon.
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.
GradleConnector.disconnect()
method is now considered stable.AntlrSourceDirectorySet
interface is now considered stable.Ear.getAppDirectory()
method is now considered stable.EclipseClasspath.getContainsTestFixtures()
method is now considered stable.The following type and method are now considered stable:
GroovySourceDirectorySet
GroovyCompileOptions.getDisabledGlobalASTTransformations()
ScalaSourceDirectorySet
interface is now considered stable.War.getWebAppDirectory()
method is now considered stable.Settings
APISettings.dependencyResolutionManagement(Action)
and Settings.getDependencyResolutionManagement()
are now considered stable.
DependencyResolutionManagement
are now stable, except the ones for central repository declaration.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.