Upgrading your build from Gradle 5.x
This chapter provides the information you need to migrate your Gradle 5.x builds to Gradle 5.1.1. For migrating from Gradle 4.x, complete the 4.x to 5.0 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 is so that you can see any deprecation warnings that apply to your build.
Alternatively, you could 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, for example 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 does try to use a deprecated part of the API.
-
Run
gradle wrapper --gradle-version 5.1.1
to update the project to 5.1.1. -
Try to run the project and debug any errors using the Troubleshooting Guide.
Upgrading from 5.0 and earlier
Potential breaking changes
The following changes were not previously deprecated:
Signing API changes
Input and output files of Sign
tasks are now tracked via Signature.getToSign()
and Signature.getFile()
, respectively.
Collection properties default to empty collection
In Gradle 5.0, the collection property instances created using ObjectFactory
would have no value defined, requiring plugin authors to explicitly set an initial value. This proved to be awkward and error prone so ObjectFactory
now returns instances with an empty collection as their initial value.
Worker API: working directory of a worker can no longer be set
Since JDK 11 no longer supports changing the working directory of a running process, setting the working directory of a worker via its fork options is now prohibited. All workers now use the same working directory to enable reuse. Please pass files and directories as arguments instead. See examples in the Worker API documentation.
Changes to native linking tasks
To expand our idiomatic Provider API practices, the install name property from org.gradle.nativeplatform.tasks.LinkSharedLibrary
is affected by this change.
-
getInstallName()
was changed to return aProperty
. -
setInstallName(String)
was removed. UseProperty.set()
instead.
Passing arguments to Windows Resource Compiler
To expand our idiomatic Provider API practices, the WindowsResourceCompile
task has been converted to use the Provider API.
Passing additional compiler arguments now follow the same pattern as the CppCompile
and other tasks.
Copied configuration no longer shares a list of beforeResolve
actions with original
The list of beforeResolve
actions are no longer shared between a copied configuration and the original.
Instead, a copied configuration receives a copy of the beforeResolve
actions at the time the copy is made.
Any beforeResolve
actions added after copying (to either configuration) will not be shared between the original and the copy.
This may break plugins that relied on the previous behaviour.
Changes to incubating POM customization types
-
The type of
MavenPomDeveloper.properties
has changed fromProperty<Map<String, String>>
toMapProperty<String, String>
. -
The type of
MavenPomContributor.properties
has changed fromProperty<Map<String, String>>
toMapProperty<String, String>
.
Changes to specifying operating system for native projects
The incubating operatingSystems
property on native components has been replaced with the targetMachines property.
Change in behavior for tasks extending AbstractArchiveTask
or subtypes (Zip
, Jar
, War
, Ear
, Tar
)
The AbstractArchiveTask
has several new properties using the [Provider API](userguide/lazy_configuration.html). Plugins that extend these types and override methods from the base class may no longer behave the same way. Internally, AbstractArchiveTask
prefers the new properties and methods like getArchiveName()
are façades over the new properties.
If your plugin/build only uses these types (and does not extend them), nothing has changed.
Deprecated classes, methods and properties
Follow the API links to learn how to deal with these deprecations (if no extra information is provided here):
-
Setters for
classes
andclasspath
onValidateTaskProperties
-
There should not be setters for lazy properties like
ConfigurableFileCollection
. UsesetFrom
instead. For example,
validateTaskProperties.getClasses().setFrom(fileCollection) validateTaskProperties.getClasspath().setFrom(fileCollection)