The Gradle team is excited to announce a new major version of Gradle, 6.0.1.
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ć.
Switch your build to use Gradle 6.0.1 by updating your wrapper:
./gradlew wrapper --gradle-version=6.0.1
See the upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 6.0.1.
NOTE: Gradle 6.0 has had one patch release fixing several issues. We recommend always using the latest patch release.
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
Other versions may or may not work.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Gradle now supports running with Java 13.
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ć.
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.
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:
HttpBuildCache.allowInsecureProtocolIvyArtifactRepository.allowInsecureProtocolMavenArtifactRepository.allowInsecureProtocolTextResourceFactory.fromInsecureUri(Object)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.
A low severity security issue was reported in the Gradle signing plugin.
More information can be found below:
This was contributed by Vladimir Sitnikov.
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.
Since 6.0.1, if your external repository doesn't support SHA256 and/or SHA512 checksums, it is possible to disable upload of those checksums:
-Dorg.gradle.internal.publish.checksums.insecure=true to the CLI orsystemProp.org.gradle.internal.publish.checksums.insecure=true to your gradle.properties fileGradle now supports in-memory signing with subkeys.
This was contributed by szhem.
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.
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.
gradle init generates .gitattributes fileTo ensure Windows batch scripts retain the appropriate line endings, gradle init now generates a .gitattributes file.
This was contributed by Tom Eyckmans.
Gradle now reports the progress of the distribution downloaded.
Initially contributed by Artur Dryomov.
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.
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.
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>.
ConfigurableFileTree and FileCollection factory methodsPreviously, 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.
FileSystemOperations and ExecOperations servicesIn 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.
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.
RegularFileProperty or DirectoryProperty and a FileGradle 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.
Gradle now supports building application and libraries with Visual Studio 2019.
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 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.
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.
The new InputChanges API for implementing incremental tasks has been promoted. See the user manual for more information.
We promoted all API elements in ide and tooling-api sub-projects that were introduced before Gradle 5.5.
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.