Gradle

• Community Open Community Menu

• Training

• News Open Community Menu

• Enterprise
• github

Gradle Release Notes

The Gradle team is excited to announce a new major version of Gradle, 6.0.

A major highlight of this release is the vastly improved feature set in dependency management. Some of the features were released in stages, but with Gradle 6.0 they are stable and production ready. We publish Gradle Module Metadata by default, which makes these new features available between projects and binary dependencies.

In the JVM ecosystem, we've made incremental Java and Groovy compilation faster, added support for JDK13 and provided out of the box support for javadoc and source jars. For Scala projects, we've updated the Zinc compiler and made it easier to select which version of Zinc to use.

For Gradle plugin authors, we've added new APIs to make it easier to lazily connect tasks and properties together, made useful services available to worker API actions and Gradle will complain at runtime if a task appears misconfigured.

In the native ecosystem, we've added support for Visual Studio 2019 and the latest C++ standards.

This release contains some updates to help protect the integrity and security of your build.

As always, we also incorporated some smaller changes and many other fixed issues.

This release features changes across the board, but these release notes only list what's new since Gradle 5.6. You can review the highlights since Gradle 5.0 here.

We would like to thank the following community contributors to this release of Gradle:

Nathan Strong, Roberto Perez Alcolea, Daniel Santiago, Tetsuya Ikenaga, Sebastian Schuberth, Andrey Mischenko, Shintaro Katafuchi, Alex Saveau, Mike Kobit, Tom Eyckmans, Artur Dryomov, szhem, Nigel Banks, Sergey Shatunov, Dan Sănduleac, Vladimir Sitnikov, Ross Goldberg, jutoft, Robin Verduijn, Pedro Tôrres, Michael Berry, Evgeny Mandrikov, lingocoder, Robert Stupp, and Predrag Knežević.

Upgrade Instructions

Switch your build to use Gradle 6.0 by updating your wrapper:

./gradlew wrapper --gradle-version=6.0

See the upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 6.0.

Compatibility Notes

A Java version between 8 and 13 is required to execute Gradle. Java 14 and later versions are not yet supported.

Java 6 and 7 can still be used for compilation and forked test execution. Just like Gradle 5.x, any supported version of Java can be used for compile or test.

This version of Gradle is tested with

• Android Gradle Plugin 3.4, 3.5 and 3.6
• Kotlin 1.3.21 through 1.3.50

Other versions may or may not work.

Dependency management improvements

The dependency management documentation has been reorganised and structured around use cases to help users find the information they need faster. We've improved the terminology section to explain the commonly used terms.

The publication of Gradle Module Metadata is now the default when using the maven-publish or ivy-publish plugins.

Many of the features below rely on the production or consumption of additional metadata not found in Ivy or Maven POM files.

Sharing dependency versions between projects

Gradle offers an easy way to recommend and share versions between projects called platforms.

With Gradle platforms, more context around version declaration are available, versions can be recommended and strict versions are enforced.

For interoperability, builds can also leverage integration with Maven BOMs.

Handling mutually exclusive dependencies

Gradle uses component capabilities to allow plugins and builds to detect and resolve implementation conflicts between mutually exclusive dependencies.

A well-known example in the JVM world is competing logging implementations. Component capabilities let builds configure which dependency to select.

Upgrading versions of transitive dependencies

Issues with dependency management are often about dealing with transitive dependencies. Often developers incorrectly fix transitive dependency issues by adding direct dependencies. To avoid this, Gradle provides the concept of dependency constraints to influence the version of transitive dependencies.

Aligning versions across multiple dependencies

Dependency version alignment allows builds to express that different modules belong to the same logical group (like a platform) and need to have identical (a.k.a aligned) versions in a dependency graph.

A well-known example in the JVM world is the Jackson libraries.

Expressing intent with context

When declaring a dependency, a build can provide more context to Gradle about its version, including version preferences within a range, strict version requirements or rejected versions. Developers can also provide human readable descriptions for why a dependency is used or needed.

Tweak published metadata

Gradle allows builds to fix or enrich traditional metadata with information that could not be published before, such as dependency constraints, rich versions, capabilities and variants. These are called component metadata rules.

Component metadata rules also make it possible to map additional published artifacts to new Gradle variants.

Modeling feature variants and optional dependencies

Gradle provides the ability to model optional features of a library. Each feature can have its own set of dependencies and can be consumed separately.

With feature variants, Gradle provides first-class support for to create and publish test fixtures. Test fixtures can be consumed by other projects in a multi-project build.

Built-in javadoc and sources packaging and publishing

You can now activate Javadoc and sources publishing for a Java Library or Java project:

java {
    withJavadocJar()
    withSourcesJar()
}

Using the maven-publish or ivy-publish plugin, this will not only automatically create and publish a -javadoc.jar and -sources.jar but also publish the information that these exist as variants in Gradle Module Metadata. This means that you can query for the Javadoc or sources variant of a module and also retrieve the Javadoc (or sources) of its dependencies.

If activated, a Java and Java Library project automatically provides the javadocJar and sourcesJar tasks.

Faster incremental Java and Groovy compilation

When analyzing the impact of a changed class, the incremental compiler can now exclude classes that are an implementation detail of another class. This limits the number of classes that need to be recompiled.

For instance, if you have:

class A {}

class B {
    static void foo() {
        A a = new A();
        // ... use A
    }
}

class C {
    void bar() {
        B.foo();
    }
}

When A is changed, Gradle previously recompiled all 3 source files, even though B did not change in a way that required C to be recompiled.

In Gradle 6.0, Gradle will only recompile A and B. For deep dependency chains, this may greatly reduce the number of files that require recompilation within a compilation task.

If A, B and C were all in different projects, Gradle would skip recompiling C through compilation avoidance.

This was contributed by Robert Stupp.

Support for Java 13

Gradle now supports running with Java 13.

Update to newer Scala Zinc compiler

The Zinc compiler has been upgraded to version 1.3.0. Gradle no longer supports building for Scala 2.9.

This fixes some Scala incremental compilation bugs and improves performance.

The minimum Zinc compiler supported by Gradle is 1.2.0 and the maximum tested version is 1.3.0.

To make it easier to select the version of the Zinc compiler, you can now configure a zincVersion property:

scala {
    zincVersion = "1.2.1"
}

Please note that the coordinates for the supported version of Zinc has changed since Zinc 1.0. If you try to use the com.typesafe.zinc:zinc compiler, Gradle will switch to the new Zinc implementation with a default version (1.3.0).

This was originally contributed by Predrag Knežević.

Problems with tasks called out during build

Tasks that define their inputs or outputs incorrectly can cause problems when running incremental builds or when using the build cache. As part of an ongoing effort to bring these problems to light, Gradle now reports these problems as deprecation warnings during the build.

When issues are detected, Gradle will show warnings when run with --warning-mode=all:

> Task :myTask
Property 'inputDirectory' is declared without normalization specified. Properties of cacheable work must declare their normalization via @PathSensitive, @Classpath or @CompileClasspath. Defaulting to PathSensitivity.ABSOLUTE. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0.
Property 'outputFile' is not annotated with an input or output annotation. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0.

Deprecation warnings will always show up in build scans regardless of the command-line arguments used.

See the user manual for how to address these deprecation warnings.

Security improvements

Protecting the integrity of builds

Gradle will now emit a deprecation warning when resolving dependencies, pulling cache hits from a remote build cache, retrieving text resources, and applying script plugins with the insecure HTTP protocol.

We encourage all users to switch to using HTTPS instead of HTTP. Free HTTPS certificates for your artifact server can be acquired from Lets Encrypt. The use of HTTPS is important for protecting your supply chain and the entire JVM ecosystem.

For users that require the use of HTTP, Gradle has several new APIs to continue to allow HTTP on a case-by-case basis.

For repositories:

repositories {
    maven {
        url = "http://my-company.example"
        allowInsecureProtocol = true
    }
    ivy {
        url = "http://my-company.example"
        allowInsecureProtocol = true
    }
}

For script plugins:

apply from: resources.text.fromInsecureUri("http://my-company.example/external.gradle")

The new APIs:

Deprecation of HTTP services

On January 13th through January 15th, 2020, some of the most widely used artifact servers in the JVM ecosystem will drop support for HTTP and will only support HTTPS. Their announcements can be found below:

We will be decommissioning the use of HTTP with Gradle provided services.

Signing Plugin now uses SHA512 instead of SHA1

A low severity security issue was reported in the Gradle signing plugin.

More information can be found below:

This was contributed by Vladimir Sitnikov.

Publication of SHA256 and SHA512 checksums

If you use the maven-publish or ivy-publish plugins, Gradle will now automatically upload SHA256 and SHA512 signatures, in addition to the traditional but unsecure MD5 and SHA1 signatures.

Publication of SHA256 and SHA512 files is not supported by the deprecated maven plugin but works with the legacy uploadArchives task for Ivy repositories.

In addition, the Gradle Module Metadata file also includes SHA256 and SHA512 checksums on referenced artifacts.

Support for in-memory signing with subkeys

Gradle now supports in-memory signing with subkeys.

This was contributed by szhem.

Usability improvements

Automatic shortening of long command-lines for Java applications on Windows

When Gradle detects that a Java process command-line will exceed Windows's 32,768 character limit, Gradle will attempt to shorten the command-line by passing the classpath of the Java application via a "classpath jar".

The classpath jar contains a manifest with the full classpath of the application. Gradle will only pass the generated jar on the command-line to the application. If the command-line is still too long, the Java process will fail to start as before.

If the command-line does not require shortening, Gradle will not change the command-line arguments for the Java process.

More consistent & robust file deletion on Windows

Deleting complex file hierarchies on Windows can sometimes fail with errors like Unable to delete directory .... In the past, Gradle has used workarounds in some but not all cases when deleting files.

Gradle now deletes files in a consistent way that should avoid failures when cleaning output files of a task.

Windows line endings: gradle init generates .gitattributes file

To ensure Windows batch scripts retain the appropriate line endings, gradle init now generates a .gitattributes file.

This was contributed by Tom Eyckmans.

Wrapper reports download progress as percentage

Gradle now reports the progress of the distribution downloaded.

Initially contributed by Artur Dryomov.

Wrapper tries to recover from an invalid Gradle installation

If the wrapper determines a Gradle distribution installed by the wrapper is invalid, the wrapper will attempt to re-install the distribution. Previous versions of the wrapper would fail and require manual intervention.

Daemon logs contain the date and timestamp

When logging messages to the Gradle daemon log, our log format only contain the time and not the date.

Gradle now logs with ISO-8601 date timestamps.

Features for plugin authors

New types available as managed properties

Gradle 5.5 introduced the concept of a managed property for tasks and other types. Gradle provides an implementation of the getters and setters for a managed property. This simplifies plugin implementation by removing a bunch of boilerplate.

In this release, it is possible for a task or other custom types to have an abstract read-only property of type ConfigurableFileTree and NamedDomainObjectContainer<T>.

New ConfigurableFileTree and FileCollection factory methods

Previously, it was only possible to create a ConfigurableFileTree or a fixed FileCollection by using the APIs provided by a Project. However, a Project object is not always available, for example in a project extension object or a worker action.

The ObjectFactory service now has a fileTree() method for creating ConfigurableFileTree instances.

The Directory and DirectoryProperty types both have a new files(Object...) method to create fixed FileCollection instances resolving files relative to the referenced directory.

See the user manual for how to inject services and how to work with files in lazy properties.

Injectable FileSystemOperations and ExecOperations services

In the same vein, doing file system operations such as copy(), sync() and delete() or running external processes via exec() and javaexec() was only possible by using the APIs provided by a Project. Two new injectable services now allow to do all that when a Project instance is not available.

See the user manual for how to inject services and the FileSystemOperations and ExecOperations api documentation for more details and examples.

Services available in Worker API actions

The following services are now available for injection in tasks that use the Worker API and the WorkAction classes:

These services can be injected by adding them to the constructor arguments of the WorkAction implementation:

abstract class ReverseFile implements WorkAction<ReverseParameters> {
    private final FileSystemOperations fileSystemOperations

    @Inject
    public ReverseFile(FileSystemOperations fileSystemOperations) {
        this.fileSystemOperations = fileSystemOperations
    }

    @Override
    public void execute() {
        fileSystemOperations.copy {
            from parameters.fileToReverse
            into parameters.destinationDir
            filter { String line -> line.reverse() }
        }
    }
}

See the user manual for further information on injecting services into custom Gradle types.

New convenience methods for bridging between a RegularFileProperty or DirectoryProperty and a File

Features for native developers

IntelliSense support for C++17 and latest C++ standard within Visual Studio

Gradle will now generate IDE solutions honoring the C++17 /std:cpp17 and latest C++ standard /std:cpplatest compiler flags.

Visual Studio IntelliSense will help you write great code with these new standards.

Support for Visual Studio 2019

Gradle now supports building application and libraries with Visual Studio 2019.

Features for Gradle tooling providers

Test output as progress event

Users of the latest Tooling API can listen to the new TestOutputEvent progress event type that contains the test output. With that, tooling providers can use the TestLauncher API to launch tests and show the test output on the fly.

Promoted features

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.

C++ and Swift support

We promoted all the new native plugins (i.e. cpp-application, cpp-library, cpp-unit-test, swift-application, swift-library, xctest, visual-studio and xcode). Note that all software model plugins will be phased out instead of being promoted.

New incremental tasks API

The new InputChanges API for implementing incremental tasks has been promoted. See the user manual for more information.

IDE integration types and APIs.

We promoted all API elements in ide and tooling-api sub-projects that were introduced before Gradle 5.5.

Some long existing incubating features have been promoted

• All pre-5.0 incubating APIs have been promoted.
• The lazy configuration API has been promoted.
• Enabling strict task validation has been promoted.

Fixed issues

131 issues have been fixed in Gradle 6.0.

• [#11162] - Break when the java or java-library is applied after java-platform is applied
• [#11140] - Change method names for javadoc and sources jar creation
• [#11121] - gradle 6.0-rc-1 throws NoSuchMethodError when using scala 2.13.1
• [#11111] - Incorrect output when publication warnings are silenced
• [#11105] - Change POM gradle metadata marker
• [#11101] - Gradle Enteprise plugin is incompatible with -b and 6.0
• [#11095] - Cannot include 5.x build using `build-scan` Kotlin plugin sugar
• [#11091] - Missing disambiguation between `category=platform` and `category=enforced-platform`
• [#11090] - Definitions from buildSrc/ not found in settings.gradle.kts using gradle 6.0-rc-1
• [#9857] - can't compile scala 2.13.0
• [#11202] - `--scan` does not work when settings script is written in Kotlin
• [#11038] - Forcing Scala 2.10/2.11 for zinc configuration does not work in 6.x nightly
• [#11021] - Module metadata failures when child POM inherits portions for name/version from parent
• [#10980] - Disable configuration matching for Gradle Module Metadata
• [#10952] - New KotlinDslScriptsModel should be into :toolingApi
• [#10924] - Binary compatibility check should fail on incompatible changes to non-incubating deprecated members
• [#10916] - Changing flag is not set on snapshots using Gradle Module Metadata
• [#10902] - com.fasterxml.jackson.core:jackson-databind Security Vulnerabilities in Gradle 5.x
• [#10885] - Fix documentationRegistry following DM docs re-organization
• [#10878] - Publishing Maven BOM without scope information
• [#10870] - Misc improvements to dependency management docs
• [#10856] - Investigate impact of failing on duplicates in JARs by default
• [#10792] - Document validation deprecation warnings
• [#10789] - Show deprecation warnings for path sensitivity problems
• [#10786] - Improve error message when module isn't found because no `artifact` source is defined
• [#10778] - Dependencies of feature variant are not added to the test classpath
• [#10777] - Consistently display owning types in validation messages
• [#10772] - Type information lost on Kotlin DSL accessors to typed Kotlin lambda extensions
• [#10759] - Plugin validation should validate plugin source set
• [#10745] - Embedded Kotlin dependencies should resolve with correct metadata
• [#10738] - Update documentation referencing Maven
• [#10737] - Document (and maybe bundle) variant aware javadoc and source publication
• [#10736] - Prevent publication of module with same variant name or equivalent variants
• [#10613] - Automagically generate an `Action`-taking configure method for extensions with container properties
• [#10533] - Fix resolved version publication for strictly
• [#10532] - Restrict feature combinations in dependency declarations
• [#10512] - Implement `forSubgraph` via `strictly`
• [#10485] - Show deprecation warnings for validation warnings at runtime
• [#10469] - Document JVM ecosystem attributes, their values and the compat / disamb rules
• [#10467] - Improve publishing chapter documentation
• [#10466] - Inherited property annotations should be merged from subtype with implemented interfaces and then with super-class
• [#10464] - Complete documentation on producing extra variant artifacts
• [#10457] - Complete documentation for dependency alignment
• [#10456] - Complete documentation on dependency platforms
• [#10455] - Improve dependency version documentation
• [#10452] - `@ReplacedBy` should work like `@Internal`
• [#10438] - Log changes to incremental and non-incremental input properties differently
• [#10431] - Add option to publication DSL to disable pom/ivy warnings
• [#10430] - Document component metadata rules
• [#10429] - Maven publish: Filter optional self-dependencies in pom.xml that originate from features depending on other features of the same component
• [#10428] - Allow modification of published variants that are added to components by plugins
• [#10427] - Document or fix inconsistencies between legacy Ivy publication and ivy-publish
• [#10420] - Better incremental compilation support
• [#10418] - JavaCompile is UP-TO-DATE even if it had to remove stale classes
• [#10356] - Deadlock in artifact transform with dependencies when resolving in a model builder
• [#10324] - @Optional not applied to getter in Kotlin
• [#10313] - Do not lock deprecated configurations when locking all configurations of a Java ecosystem project
• [#10312] - Generate @Deprecated annotations for configuration accessors in Kotlin DSL
• [#10309] - HTTP Downloading of Dependencies is formally Deprecated
• [#10276] - De-incubate features for 6.0 (build-cache)
• [#10271] - Javadoc for TaskOutputs.files() shouldn't talk about disabling cache anymore
• [#10254] - Make Antlr task use InputChanges
• [#10228] - Deprecate AbstractCompile.compile()
• [#10227] - Use Deleter to clean up stale classes
• [#10226] - Use Deleter to clean up output files when loading from cache
• [#10199] - Consider not following symlinks when removing outputs
• [#10190] - Gradle Module Metadata - publish by default
• [#10189] - Gradle Module Metadata - publish and consume classifier information on dependencies
• [#10155] - Prefer loopback bind address for daemon communications
• [#10114] - Mitigate long classpath on Windows for JavaExec
• [#10102] - Update Worker API guide to reflect new API
• [#10094] - Improve performance of scheduler in the presence of many nodes
• [#10085] - Deprecate WorkerExecutor.submit()
• [#10062] - Remove CompilerArgumentProvider
• [#10033] - Deadlock scheduling finalizer task on failed build
• [#10011] - Clean fails with NPE with instant execution
• [#10009] - ImmutableList is not deserialized correctly using instant execution
• [#10003] - Deserializing MapProperty fails with instant execution
• [#10000] - Make project.exec available in task action with instant execution
• [#9888] - Revert automatic upgrade of capabilitlies
• [#9817] - Use InputChanges API in JavaCompile
• [#9723] - Tasks without outputs shouldn't be up-to-date
• [#9684] - Design and implement feature for downgrading versions of transitive dependencies
• [#9621] - De-incubate dependency management related API
• [#9618] - JMH fails after some changes in 28th of May
• [#9583] - have gradle init also create the .gitattributes file
• [#9473] - using a plugins DSL block for subprojects in a precompiled script plugin neither works not errors
• [#9462] - Incorrect snapshot resolution with Gradle metadata
• [#9437] - Deprecate JavaScript plugins
• [#9433] - Remove OSGi plugin
• [#9432] - Remove announce plugin
• [#9431] - Remove build-comparison plugin
• [#9430] - Remove FindBugs plugin
• [#9429] - Remove JDepend plugin
• [#9422] - Kotlin DSL IntelliJ script resolution miss configured environment variables
• [#9408] - Deprecate legacy publishing plugins (maven and ivy)
• [#9378] - Warning about capability when building POM for publishing
• [#9299] - Let the Kotlin DSL IDE script editor resolver support non-jvm IJ projects
• [#9269] - Add deprecation warnings to "deprecated" generated Kotlin DSL accessors for improved IDE and script compilation experience
• [#9255] - Kotlin DSL `KotlinBuildScript` should not implement the `Project` interface
• [#9083] - Fail task validation on warning by default
• [#9039] - Remove custom local build cache option
• [#9033] - Fail build for pack/unpack errors
• [#9031] - Rename ValidateTaskProperties to ValidateParameters
• [#8904] - Improve provider error message when no value has been specified
• [#8792] - CVE-2019-9658: Gradle depends upon Checkstyle Version vulnerable to MITM based XXE
• [#8788] - Scala plugin is not compatible with `java-library` plugin
• [#8684] - BuildCache unpack and CleanupStaleOutputsExecuter fails on Windows with UnrecoverableUnpackingException due to file deletion fails
• [#8681] - Gradle fails on openjdk-13
• [#8667] - Ability to silence POM compatibility warnings
• [#8585] - Deprecation warning for deprecated configurations
• [#7888] - Fail when resolving a dependency with Gradle metadata that has no variants defined
• [#7613] - Deprecate BuildListener.buildStarted
• [#7558] - Update java-library plugin documentation to describe the performance benefits over java plugin.
• [#7401] - Add api/impl separation within a single sourceset to incremental compiler
• [#6926] - Deprecate `startParameter.searchUpwards` and `startParameter.useEmptySettings()`
• [#6918] - Deprecate execution of Gradle for an undefined build
• [#6821] - TaskInputs.getProperties() result mutation should be disallowed/documented
• [#6362] - Playframework 2.7 support
• [#5468] - Provide public cancellation API
• [#5217] - Warn about deprecated configurations like `compile`
• [#4940] - Deprecate Upload-based publishing infrastructure
• [#4241] - Build path for non root builds cannot be queried until part way through the build's lifecycle
• [#4049] - Document Gradle module metadata
• [#3165] - Promote ComponentMetadata and friends out of incubation
• [#2903] - gradlew wrapper script fails on system with non-Bash /bin/sh shell
• [#2678] - Make useful services available to workers in Worker API
• [#2158] - Scala compilation with sbt/zinc
• [#1494] - 'java-gradle-plugin' should use the 'java-library' over the 'java' plugin
• [#1135] - afterEvaluate closure ignored when added to an evaluated project
• [#1084] - Maven POM resolution leads to StackOverflowError if parent GAVs reference resolved POM GAVs

Known issues

Known issues are problems that were discovered post release that are directly related to changes made in this release.

16 issues are known to affect Gradle 6.0.

• [#13224] - Broken non-incremental compilation with Scala
• [#12729] - ReplaceTokens filter fails to work in java processResources step with gradle 6.3
• [#12536] - Constraints can sometimes impact excludes
• [#12011] - Capability conflicts not always detected (when coming from transitive dependencies)
• [#11825] - Same dependencies with different classifiers are not consumed correctly from Gradle Module Metadata
• [#11639] - Pin snapshot not working
• [#11503] - Gradle 5.6.x with enforcedPlatform transitives resolution selects lowest revision
• [#11371] - Cannot run main methods from IDEA 2019.2.x with Gradle 6.0
• [#11365] - Attribute disambiguation rule for 'org.gradle.category' can cause unexpected type exception
• [#11335] - Kotlin DSL: `fileTree(mapOf(...))` has unexpected behavior
• [#11330] - Incremental Java compilation is broken with Android 3.5.1 and Gradle 6.0
• [#11321] - Unable to properly resolve dynamic dependencies from mavenLocal() repo
• [#11308] - maven-metadata.xml SHA256 and SHA512 checksums prevent publishing to Nexus
• [#11301] - Regression when root composite project refers to included builds
• [#11300] - Implicit capabilities not always applied/detected
• [#11054] - Unable to use a Provider as an artifact for the maven-publish plugin

External contributions

We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.

Reporting Problems

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.