Upgrading your build from Gradle 5.x

Using a custom build cache implementation for the local build cache is now deprecated. The only allowed type will be DirectoryBuildCache going forward. There is no change in the support for using custom build cache implementations as the remote build cache.

The Google Hosted Libraries URL accessible via JavaScriptRepositoriesExtension#GOOGLE_APIS_REPO_URL was changed to use the HTTPS protocol. The change also affect the Ivy repository configured via googleApis().

There was a bug from Gradle 5.0 to 5.2.1 (included) where enforced platforms would potentially include dependencies instead of constraints. This would happen whenever a POM file defined both dependencies and "constraints" (via <dependencyManagement>) and that you used enforcedPlatform. Gradle 5.3 fixes this bug, meaning that you might have differences in the resolution result if you relied on this broken behavior. Similarly, Gradle 5.3 will no longer try to download jars for platform and enforcedPlatform dependencies (as they should only bring in constraints).

If you apply any of the Java plugins, Gradle will now do its best to select dependencies which match the target compatibility of the module being compiled. What it means, in practice, is that if you have module A built for Java 8, and module B built for Java 8, then there’s no change. However if B is built for Java 9+, then it’s not binary compatible anymore, and Gradle would complain with an error message like the following:

In general, this is a sign that your project is misconfigured and that your dependencies are not compatible. However, there are cases where you still may want to do this, for example when only a subset of classes of your module actually need the Java 9 dependencies, and are not intended to be used on earlier releases. Java in general doesn’t encourage you to do this (you should split your module instead), but if you face this problem, you can workaround by disabling this new behavior on the consumer side:

If you have a Maven dependency pointing to an Ivy dependency where the default configuration dependencies do not match the compile + runtime + master ones and that Ivy dependency was substituted (using a resolutionStrategy.force, resolutionStrategy.eachDependency or resolutionStrategy.dependencySubstitution) then this fix will impact you. The legacy behaviour of Gradle, prior to 5.0, was still in place instead of being replaced by the changes introduced by improved pom support.

Gradle no longer ignores the followSymlink option on Windows for the clean task, all Delete tasks, and project.delete {} operations in the presence of junction points and symbolic links.

In previous Gradle versions, additional artifacts registered at the project level were not published by maven-publish or ivy-publish unless they were also added as artifacts in the publication configuration.

With Gradle 5.3, these artifacts are now properly accounted for and published.

This means that artifacts that are registered both on the project and the publication, Ivy or Maven, will cause publication to fail since it will create duplicate entries. The fix is to remove these artifacts from the publication configuration.

Input and output files of Sign tasks are now tracked via Signature.getToSign() and Signature.getFile(), respectively.

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.

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.

To expand our idiomatic Provider API practices, the install name property from org.gradle.nativeplatform.tasks.LinkSharedLibrary is affected by this change.

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.

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.

The incubating operatingSystems property on native components has been replaced with the targetMachines property.