Gradle Release Notes

Version 6.1-rc-2

The Gradle team is excited to announce Gradle 6.1-rc-2.

This release supports a relocatable dependency cache, makes compilation order between Java, Groovy and Scala classes configurable and kicks off a new set of downloadable samples.

There are also several bug fixes, conveniences for Gradle plugin authors and more.

We would like to thank the following community contributors to this release of Gradle: Mark Nordhoff, Kazuki Matsuda, Andrew Malyhin, Emmanuel Guérin, Nicholas Gates, Bjørn Mølgård Vester, Johnny Lim, Benjamin Muskalla, Ian Kerins, Vladimir Sitnikov, Michael Ernst, Nelson Osacky, Dmitriy Konopelkin, and Steven Crockett.

Upgrade Instructions Switch your build to use Gradle 6.1-rc-2 by updating your wrapper: ./gradlew wrapper --gradle-version=6.1-rc-2 See the Gradle 6.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 6.1-rc-2. For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.

Gradle's Dependency Cache can be relocated The Gradle Dependency cache under $GRADLE_HOME/caches/modules-2 can now be relocated to another directory or host for dependencies cached by Gradle 6.1 and later. When moved to a new location or seeded into a host image, builds using the dependency cache will not need to access the network to download artifacts or metadata if the dependencies have already been downloaded. Note that the cache should be primed and consumed by same Gradle version for maximum effect. See the documentation for more details. This is just one step along the way to help organizations using ephemeral CI agents to reduce the overhead of downloading dependencies during the build.

Defining compilation order between Groovy, Scala and Java Previously, the relationship between Java, Groovy and Scala compilation was hardcoded with explicit task dependencies in the same project. Gradle assumed Groovy and Scala compilation would always depend on Java compilation. That is, compileGroovy and compileScala would directly depend on the output from compileJava . These task dependencies have been remodelled using directory properties. The relationship between compilation tasks is expressed in the task's classpath. Removing a directory property from the classpath also removes the corresponding task dependency. This can be used to change the relationship between Java, Groovy and Scala compilation tasks. For example, when combining Groovy and Kotlin in the same project, it was previously difficult to make Kotlin classes depend on Groovy classes. tasks.named('compileGroovy') { // Groovy only needs the declared dependencies // and not the output of compileJava classpath = sourceSets.main.compileClasspath } tasks.named('compileKotlin') { // Kotlin also depends on the result of Groovy compilation // which automatically makes it depend of compileGroovy classpath += files(sourceSets.main.groovy.classesDirectory) }

Groovy compilation support for method parameter names with JDK8+ Gradle 6.1 supports compiling Groovy code and including method parameter names. This was contributed by Andrew Malyhin.

Improvements for plugin authors Finalize property value only when the value is queried In previous Gradle releases, certain Gradle types, such as Property or ConfigurableFileCollection , provided a finalizeValue() method that eagerly calculated the final value for a property and prevented further changes. When a task starts running, Gradle automatically finalizes task properties of these types, so that the same value is seen by the task's actions and Gradle's build caching/up-to-date checks. This also avoids calculating the property value multiple times, which can sometimes be expensive. Plugins can also use finalizeValue() to finalize other properties, such as a property of a project extension, just prior to querying the value. In this release, these types gain a new finalizeValueOnRead() method. This method is similar to finalizeValue() , except that the final value is calculated when the value is queried rather than immediately. Plugins can use this method when a property value may be expensive to calculate or when the value may not have been configured to ensure that all consumers of the property see the same, final, value from that point onwards. Please see the user manual for more details. New managed property types Gradle 5.5 introduced the concept of a managed property for tasks and other types, where Gradle provides an implementation of the getter and setter for an abstract property defined on a task, project extension, or other custom type. This simplifies plugin implementations by removing a bunch of boilerplate. In this release, it is possible for a task or other custom type to have an abstract read-only property of type DomainObjectSet<T> . Please see the user manual for more details. New factory methods The ObjectFactory type, which plugins and other custom types use to create instances of various useful types, has several new factory methods to create certain Gradle types that could only be created using internal APIs in previous releases: The polymorphicDomainObjectContainer() method to create ExtensiblePolymorphicDomainObjectContainer<T> instances.

method to create instances. The namedDomainObjectSet() method to create NamedDomainObjectSet<T> instances.

method to create instances. The namedDomainObjectList() method to create NamedDomainObjectList<T> instances. Please see the user manual for more details.

Improvements for Gradle tooling providers Tooling API: TestLauncher can run specific Test task tests The TestLauncher interface in the Tooling API could already launch tests by specifying the name of the test classes or methods; however, if there are multiple Test tasks, then all Test tasks would be executed. For IDEs, developers usually want to execute only one task at a time. Gradle 6.1 introduces a new API to execute tests with specific Test task using the withTaskAndTestClasses() and withTaskAndTestMethods() methods.

Fixed issues

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

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