This chapter provides the information you need to migrate your Gradle 9.x.y builds to the latest. For migrating to Gradle 9.0.0, see the older migration guide first.
We recommend the following steps for all users:
-
Try running
gradle help --scan
and view the deprecations view of the generated Build Scan.This lets you see any deprecation warnings that apply to your build.
Alternatively, you can run
gradle help --warning-mode=all
to see the deprecations in the console, though it may not report as much detailed information. -
Update your plugins.
Some plugins will break with this new version of Gradle because they use internal APIs that have been removed or changed. The previous step will help you identify potential problems by issuing deprecation warnings when a plugin tries to use a deprecated part of the API.
-
Run
gradle wrapper --gradle-version 9.1.0
to update the project to 9.1.0. -
Try to run the project and debug any errors using the Troubleshooting Guide.
Upgrading from 9.0.0 and earlier
Deprecations
Deprecation of multi-string dependency notation
In an effort to simplify and standardize the Gradle API, the multi-string dependency notation used in dependency management has been deprecated and will no longer be permitted in Gradle 10. Gradle will primarily accept dependency declarations in the form of a single string, with each dependency coordinate separated by a colon.
Below are examples of the deprecated multi-string notation:
dependencies {
implementation(group = "org", name = "foo", version = "1.0")
implementation(group = "org", name = "foo", version = "1.0", configuration = "conf")
implementation(group = "org", name = "foo", version = "1.0", classifier = "classifier")
implementation(group = "org", name = "foo", version = "1.0", ext = "ext")
}
testing.suites.named<JvmTestSuite>("test") {
dependencies {
implementation(module(group = "org", name = "foo", version = "1.0"))
}
}
dependencies {
implementation(group: 'org', name: 'foo', version: '1.0')
implementation(group: 'org', name: 'foo', version: '1.0', configuration: 'conf')
implementation(group: 'org', name: 'foo', version: '1.0', classifier: 'classifier')
implementation(group: 'org', name: 'foo', version: '1.0', ext: 'ext')
}
testing.suites.test {
dependencies {
implementation(module(group: 'org', name: 'foo', version: '1.0'))
}
}
These declarations should be replaced with the single-string notation:
dependencies {
implementation("org:foo:1.0")
implementation("org:foo:1.0") {
targetConfiguration = "conf"
}
implementation("org:foo:1.0:classifier")
implementation("org:foo:1.0@ext")
}
testing.suites.named<JvmTestSuite>("test") {
dependencies {
implementation("org:foo:1.0")
}
}
dependencies {
implementation("org:foo:1.0")
implementation("org:foo:1.0") {
targetConfiguration = "conf"
}
implementation("org:foo:1.0:classifier")
implementation("org:foo:1.0@ext")
}
testing.suites.test {
dependencies {
implementation("org:foo:1.0")
}
}
In some cases, a complete single-string notation may not be known up front.
Instead of concatenating the coordinates into a new string, it is possible to use a DependencyFactory
to create Dependency
instances directly from the individual components:
val group = "org"
val artifactId = "foo"
val version = "1.0"
configurations.dependencyScope("implementation") {
dependencies.add(project.dependencyFactory.create(group, artifactId, version))
}
def group = "org"
def artifactId = "foo"
def version = "1.0"
configurations.dependencyScope("implementation") {
dependencies.add(project.dependencyFactory.create(group, artifactId, version))
}
Deprecation of ReportingExtension.file(String)
The file()
method on ReportingExtension
has been deprecated and will be removed in Gradle 10.0.0.
Instead, use ReportingExtension.getBaseDirectory()
with file(String)
or dir(String)
.
Deprecation of ReportingExtension.getApiDocTitle()
The getApiDocTitle()
method on ReportingExtension
has been deprecated and will be removed in Gradle 10.0.0.
There is no direct replacement for this method.
Deprecation of JavaForkOptions.setAllJvmArgs()
The setAllJvmArgs()
method on JavaForkOptions
and, by inheritance, on JavaExecSpec
has been deprecated and will be removed in Gradle 10.0.0.
Instead, to overwrite existing JVM arguments, use:
-
JavaForkOptions.jvmArgs()
-
JavaForkOptions.setJvmArgs()
-
Provide a
CommandLineArgumentProvider
to add arguments viaJavaForkOptions.getJvmArgumentProviders()
Note that setAllJvmArgs()
method on JavaForkOptions
cleared all fork options before setting jvmArgs
.
The properties cleared included:
-
System properties configured via
JavaForkOptions.systemProperties
-
JVM argument providers configured via
JavaForkOptions.jvmArgumentProviders
-
Argument providers configured via
JavaExecSpec.argumentProviders
-
Memory settings configured via
JavaForkOptions.minHeapSize
andJavaForkOptions.maxHeapSize
-
All other JVM arguments configured via
JavaForkOptions.jvmArgs
-
The assertion and debug flags configured via
JavaForkOptions.enableAssertions
andJavaForkOptions.debug
If the arguments you provide to setJvmArgs()
or jvmArgs()
depend on any of the above properties being cleared, you will need to manually clear them.
Consider the following snippets for examples of how to implement this change:
plugins {
id("java")
}
tasks.register<JavaExec>("myRunTask") {
jvmArgumentProviders.clear() // Clear existing JVM argument providers
maxHeapSize = null // Clear max heap size
jvmArgs = listOf("-Dfoo", "-Dbar") // Set new JVM arguments
}
plugins {
id("java")
}
tasks.named('myRunTask', JavaExec) {
jvmArgumentProviders.clear() // Clear existing JVM argument providers
maxHeapSize = null // Clear max heap size
jvmArgs = ["-Dfoo", "-Dbar"] // Set new JVM arguments
}
Deprecation of archives
configuration
The archives
configuration added by the base
plugin has been deprecated and will be removed in Gradle 10.0.0.
Adding artifacts to the archives
configuration will now result in a deprecation warning.
If you want the artifact to be built when running the assemble
task, add the artifact (or the task that produces it) as a dependency on assemble
:
val specialJar = tasks.register<Jar>("specialJar") {
archiveBaseName.set("special")
from("build/special")
}
tasks.named("assemble") {
dependsOn(specialJar)
}
Deprecation of the Configuration.visible
property
Prior to Gradle 9.0.0, any configuration with isVisible()
returning true
would implicitly trigger artifact creation when running the assemble
task.
This behavior was removed in Gradle 9.0.0, and the Configuration.visible
property no longer has any effect.
The property is now deprecated and will be removed in Gradle 10.0.0.
You can safely remove any usage of visible
.
If you want the artifacts of a configuration to be built when running the assemble
task, add an explicit task dependency on assemble
:
val specialJar = tasks.register<Jar>("specialJar") {
archiveBaseName.set("special")
from("build/special")
}
configurations {
consumable("special") {
outgoing.artifact(specialJar)
}
}
tasks.named("assemble") {
dependsOn(specialJar)
}
Deprecation of non-string projectProperties
in GradleBuild
task
The GradleBuild
task now deprecates using non-String values in startParameter.projectProperties
.
While the type is declared as Map<String, String>
, there was no strict enforcement, allowing non-String values to be set.
This deprecated behavior will be removed in Gradle 10.0.0.
If you are using non-String values in project properties, convert them to String
representation:
val myIntProp = 42
tasks.register<GradleBuild>("nestedBuild") {
startParameter.projectProperties.put("myIntProp", "$myIntProp") // Convert int to String
}
def myIntProp = 42
tasks.register('nestedBuild', GradleBuild) {
startParameter.projectProperties.put('myIntProp', "$myIntProp") // Convert int to String
}
Potential breaking changes
Upgrade to ASM 9.8
ASM was upgraded from 9.7.1 to 9.8 to ensure earlier compatibility for Java 25.
Upgrade to Groovy 4.0.28
Groovy has been updated to Groovy 4.0.28.