Table Of Contents

• New and noteworthy
  • Console upgrade
  • Faster builds with the Gradle Build Cache
  • Plugin resolution rules
  • Kotlin Build Scripts
  • More work avoidance when using@Classpath task properties
  • Extensions now have a public type
  • Tooling API improvements
  • Support for multi-value Javadoc options
  • Use Java home to choose toolchain for cross compilation
• Promoted features
  • Wrapper Plugin
  • Build Init Plugin
• Fixed issues
• Deprecations
  • pluginRepositories block superseded
  • Specifying the executable for forking Java compilation is deprecated
• Potential breaking changes
  • Groovy upgraded from 2.4.7 to 2.4.10
  • Core extensions should be addressed by their public type
  • Changed ordering of "release" in version comparator
  • Version of Checkstyle has been upgraded
  • New subtype of Tooling APIProgressEvent
• External contributions
• Known issues

New and noteworthy

Here are the new features introduced in this Gradle release.

Console upgrade

When attached to a terminal, Gradle will now show you abuild summary and more detailedwork-in-progress. The build summary tells you how much of the task graph has been completed. The work-in-progress section tells you which tasks are being processed. It gets much more interesting when you turn on--parallel.

If you encounter any problems, use the--console plain option and please file an issue with your environment and terminal information.

Faster builds with the Gradle Build Cache

This release adds the Gradlebuild cache that speeds up builds by reusing outputs produced by other builds. The build cache works by storing (locally or remotely) build outputs and allowing builds to fetch these outputs from the cache when it is determined that inputs have not changed, avoiding the expensive work of regenerating them.

A first feature using the build cache istask output caching. Task output caching leverages the same intelligence asup-to-date checks that Gradle uses to avoid work when a previous local build has already produced a set of task outputs. But instead of being limited to the previous build in the same workspace, task output caching allows Gradle to reuse task outputs from any earlier build in any location on the local machine. When using a shared build cache for task output caching this even works across developer machines and build agents.

After upgrading to 3.5, try out the Gradle Build Cache straightaway on a project that uses the Java plugin by running:

gradle --build-cache clean assemblegradle --build-cache clean assemble

Your second build should be faster because some task outputs, like Java classes, can be reused from the first build. These outputs are pulled from the Gradle build cache.

In this simple example it was the same build in the same workspace which produced the outputs, but these could have also been produced by an earlier build in a different workspace, when having worked on the same branch earlier while switching branches in between or even by another developer or build agent.

Without any extra configuration, your build will use a local directory in yourGRADLE_USER_HOME to store task outputs. To take this to another level, you can configure your build to pull task outputs from a build cacheshared with your team. You canconfigure nginx to act as a shared build cache. A scalable, highly-available build cache backend is coming soon inGradle Enterprise.

We provide arecommended configuration that uses your continuous integration builds to populate a shared build cache and allows all developers to pull from that build cache. Our recommended configuration does not directly share task outputs among developer builds.

Task output caching is an opt-in feature for tasks, so not every task will be cacheable yet. For example, tasks from the Gradle Android and Kotlin plugins are not cacheableyet. Further, some tasks like a simpleCopy task are not andshould not be cached. Look atthe build cache user guide chapter to see all of the current limitations with using the build cache.

Plugin resolution rules

Gradle now allows you toadjust how plugins are resolved by providing plugin resolution rules. For instance, you could specify a default version for a plugin so you don't have to repeat it in every project. Or you could tell Gradle what implementation artifact it should look for in case the plugin is not published with plugin markers.

pluginManagement {    repositories {        maven { url = 'someUrl'}    }    resolutionStrategy {        eachPlugin {            if (requested.id.namespace = 'my.plugins') {                useVersion('1.3')            }        }    }}

ThepluginManagement block supersedes the existingpluginRepositories block. Moreover, you now have full access to theSettings DSL inside that block, so you can make decisions e.g. based on start parameters. You can also configure plugin management from an init script by using thesettingsEvaluated {} hook.

Kotlin Build Scripts

Gradle Script Kotlin v0.8.0, included in Gradle 3.5, greatly improves the user experience and parity with Groovy build scripts.

Updates since v0.5.1:

• Uses the greatKotlin 1.1 release which in itself brings a lot of fixes, including the ability to use thekotlin-gradle-plugin 1.0.x again.
• Better error reporting with location of compilation errors and clickable links.
• Plugins can be applied by string id and version within the newly introduced plugins block.
• Builtin plugins can be applied via a type-safe and tooling-friendly DSL.
• Thedreadedit problem is now solved, that means a consistent DSL across core and community plugins.
• Many methods in the Gradle API previously only available to Groovy have been overloaded with versions better suited to Kotlin.

... and a lot more. Full details are available in the Gradle Script Kotlinv0.6.0,v0.7.0 andv0.8.0 release notes.

More work avoidance when using@Classpath task properties

For built-in and custom tasks that use the@Classpath annotation, Gradle now performs deeper inspection of the classpath to filter out some differences that do not affect task execution. Gradle will ignore changes to timestamps within a jar file and the order of entries inside a jar file.

In previous versions, for tasks likeJavadoc,Checkstyle andTest, Gradle would consider the task out-of-date if the content of the classpath changed in any way (order of classes in a jar, timestamps of class files, etc).

Extensions now have a public type

Extensions can now be registered inExtensionContainers with an explicit public type. This allows plugin authors to hide their implementation type from build scripts and allowExtensionContainers to expose a schema of all the registered extensions.

For example, if you have aFancyExtension type, implemented by someDefaultFancyExtension type, here is how you should register it:

// If you want to delegate the extension instance creation to Gradle:project.extensions.create FancyExtension, 'fancy', DefaultFancyExtension// Or if you need to create the extension instance yourself:FancyExtension fancyInstance = new DefaultFancyExtension(...)project.extensions.add FancyExtension, 'fancy', fancyInstance

Tooling API improvements

Support for multi-value Javadoc options

Gradle has added support for command-line options to doclets that can appearmultiple times and have multiple values.

In previous versions of Gradle, it was not possible to supply command-line options like:

-myoption 'foo' 'bar'-myoption 'baz'

Gradle would produce a single-myoption or combine the option's value into a single argument.

javadoc {    options {        def myoption = addMultilineMultiValueOption("myoption")        myoption.setValue([            [ "foo", "bar" ],            [ "baz" ]        ])    }}

Use Java home to choose toolchain for cross compilation

For selecting a Java toolchain for cross compilation you can now useForkOptions.javaHome. Gradle will detect the version of the Java installation and use the right compiler from the installation. SettingForkOptions.executable has been deprecated in favor of this new way of choosing the Java compiler for cross-compilation.

For more information on how to use this feature see thedocumentation on cross-compilation.

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 guide section on the “Feature Lifecycle” for more information.

The following are the features that have been promoted in this Gradle release.

Wrapper Plugin

TheGradle Wrapper has been unchanged for quite some time and is the most popular way to manage Gradle versions.

Build Init Plugin

gradle init has been stable for quite some time as well and has been promoted from incubating.

Fixed issues

Deprecations

Features that have become superseded or irrelevant due to the natural evolution of Gradle becomedeprecated, and scheduled to be removed in the next major Gradle version (Gradle 4.0). See the User guide section on the “Feature Lifecycle” for more information.

The following are the newly deprecated items in this Gradle release. If you have concerns about a deprecation, please raise it via theGradle Forums.

pluginRepositories block superseded

ThepluginRepositories method insettings.gradle is superseded by the newpluginManagement.repositories method.

Specifying the executable for forking Java compilation is deprecated

TheForkOptions.executable property has been deprecated. You shouldset the Java home to choose a toolchain for cross compilation.

Potential breaking changes

Groovy upgraded from 2.4.7 to 2.4.10

The version of Groovy bundled with Gradle has been upgraded to2.4.10.

Core extensions should be addressed by their public type

Now that extensions implementation type is hidden from plugins and build scripts that extensions can only be addressed by their public type, some Gradle core extensions are not addressable by their internal type anymore:

• DefaultExtraPropertiesExtension, useExtraPropertiesExtension instead
• DefaultDistributionContainer, useDistributionContainer instead
• DefaultPublishingExtension, usePublishingExtension instead
• DefaultPlatformContainer, usePlatformContainer instead
• DefaultBuildTypeContainer, useBuildTypeContainer instead
• DefaultFlavorContainer, useFlavorContainer instead
• DefaultNativeToolChainRegistry, useNativeToolChainRegistry instead

Changed ordering of "release" in version comparator

"RELEASE" is now considered a special term when comparing versions of dependencies. It is now consideredhigher than "DEV" or "RC" (all things case-insensitive). This allows projects like those using Spring to have correct version comparison.

Seegradle/gradle#1378 for more details.

Version of Checkstyle has been upgraded

By default, Gradle now usesCheckstyle 6.19. Previously, Gradle used Checkstyle 5.9. We cannot upgrade to the latest release because Checkstyle 7.0+ require Java 8. Gradle has been tested against Checkstyle 7.0 and 7.6.

Newer versions of Checkstyle usually bring new rules, better inspections and bug fixes. Your build may fail due to these changes.

You can upgrade or downgrade the version of Checkstyle with:

checkstyle {    toolVersion = '5.9'}

New subtype of Tooling APIProgressEvent

A new subtype of the Tooling API typeProgressEvent, calledStatusEvent, has been added to represent the interim progress of a particular operation. Instances of this new type will be passed toProgressListener.statusChanged().

External contributions

We would like to thank the following community members for making contributions to this release of Gradle.

• Ethan Hall - Plugin resolution rules (gradle/gradle#1343)
• Lucas Smaira - BuildActionExecutor.forTasks() support (gradle/gradle#1442)
• Vladislav Soroka - Allow environment variables to be configured through Tooling API (gradle/gradle#1029)
• Vladislav Soroka - Tooling API reports Gradle distribution download progress (gradle/gradle#1182)
• Jacob Beardsley - FixNullPointerException when excluding transitive dependencies in dependency configuration (gradle/gradle#1113)
• Attila Kelemen - Project.file supports java.nio.file.Path instances (gradle/gradle#813)
• Kevin Page - Eclipse resource filters (gradle/gradle#846)
• Björn Kautler - Update user guide for build comparison about supported builds (gradle/gradle#1266)
• Joshua Street - Align usage ofgroovy-all dependency across multiple example in user guide (gradle/gradle#1446)
• Thomas Broyer - Fix SourceSet.compileClasspath default value documentation (gradle/gradle#1329)
• Erhan Karakaya - Fix bug in generating distributionUrl in Thurkish locale (gradle/gradle#1408)
• Endre Fejes - Fixing EOL to be platform specific for--version (gradle/gradle#1462)
• Eitan Adler - Minor tests cleanup (gradle/gradle#1219)

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

Known issues

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