Gradle Release Notes

Version 4.2.1

The Gradle team is pleased to announce Gradle 4.2.

First and foremost, progress has been made to improve Gradle's support for building native applications. The first outcome is parallel task execution for native compilation and linking tasks by default. This has reduced build times for native performance scenarios by as much as half.

Native apps aren't the only ones that will benefit from upgrading to Gradle 4.2. We've been working hard to ensure the build cache introduces very little overhead; builds that resolve all task outputs from the local build cache are up to 20% faster due to improvements in unpacking. Another significant performance improvement comes from zipTree and tarTree now avoiding redundant tree visitation.

Gradle 4.2 performance

Next up, first-class support for Google Cloud Storage backed repositories! You can publish and consume using the ivy-publish and maven-publish plugins. This works similarly to our Amazon S3 support, check out the samples in the user manual.

Play framework support is upgraded in Gradle 4.2: Play v2.6, built-in Twirl template types and user-defined Twirl formats are now supported. This version of Gradle introduces new on-demand rebuild and reload for PlayRun. This is different from --continuous build and gives a more pleasant development experience for some workflows.

Gradle Kotlin DSL v0.11.1 (included in this release) brings the latest and greatest Kotlin (1.1.4-3) and takes big steps toward general usability with utilities for Groovy-heavy DSLs such as Maven POM customization, Ant usage and those provided by Groovy-based community plugins. Other improvements include better Gradle API null-safety, new samples, and improvements to the kotlin-dsl plugin.

Kotlin DSL 0.11.1 IntelliJ

Last but not least, if your custom plugin is using the Instantiator (most-used internal API according to BigQuery public GitHub data), please migrate to the ObjectFactory API for nested DSLs, new in Gradle 4.2.

Important deprecation notices:

We are deprecating Gradle's RuleSource and implementing native support in the current model. Information and roadmap in our post "State and future of the Gradle Software Model".

Support for running Gradle on Java 7 is deprecated and will be removed in Gradle 5.0; Java 7 reached end-of-life in April 2015. However, you will still be able to compile, test, generate Javadoc and execute applications for Java 6 and Java 7 using cross-compilation. Please let us know if the deprecation renders to be a significant blocker for your organization by raising an issue or opening a discussion on the Gradle forum.

We hope you will build happiness with Gradle 4.2, and we look forward to your feedback via Twitter or on GitHub.

Table Of Contents

New and noteworthy

Here are the new features introduced in this Gradle release.

Performance improvements

Parallel native compilation and linking tasks

Native compile and link tasks now execute in parallel by default, making native builds faster than ever. This means that when two (or more) compile or link tasks have no dependencies on each other, they can execute simultaneously (up to the max-workers limit for each Gradle invocation). The resulting performance improvement is highly dependent on project and component structure (for instance, the more inter-dependencies there are between components, the less opportunity there is to execute tasks in parallel) but in our testing, native build times have improved by as much as 50% or more.

Faster zipTree and tarTree

The zipTree and tarTree implementations had a major performance issue, unpacking files every time the tree was traversed. This has now been fixed and should speed up builds using these trees a lot.

Better support for script plugins from HTTP/HTTPS URLs

Script plugins are applied to Gradle settings or projects with apply from: 'URL'.

Support for script plugins from http:// and https:// URLs has been improved:

Support for Google Cloud Storage backed repositories

It is now possible to consume dependencies from, and publish to, Google Cloud Storage buckets when using MavenArtifactRepository or IvyArtifactRepository.

repositories {
    maven {
        url "gcs://someGcsBucket/maven2"
    }

    ivy {
        url "gcs://someGcsBucket/ivy"
    }
}

Downloading dependencies from Google Cloud Storage is supported for Maven and Ivy type repositories as shown above. Publishing to Google Cloud Storage is supported with both the Ivy Publishing and Maven Publishing plugins, as well as when using an IvyArtifactRepository with an Upload task (see section publishing artifacts of the user guide).

Please see the repositories section of the dependency management chapter in the user guide for more information on configuring Google Cloud Storage repository access.

Better Play support

Support for Play 2.6

Gradle now supports Play applications built with Play 2.6.

By default, Gradle still uses Play 2.3.10. Change the version of Play you're using with:

model {
    components {
        play {
            platform play: '2.6.2', scala: '2.11'
        }
    }
}

Requests to a running Play application will block until all changes are incorporated

The PlayRun task is used to start a Play application from within Gradle, keeping the application up-to-date with any source changes made after startup.

In earlier versions of Gradle, an HTTP request to the running Play application may have been served by an application in a 'stale' state, where file changes had not yet been fully rebuilt and reloaded.

In Gradle 4.2, this has been fixed, and an HTTP request to the running Play application will block until all pending changes have been incorporated.

On-demand rebuild and reload for PlayRun

When a Play application is started with PlayRun, Gradle will monitor the input files for changes. Gradle now supports 2 different rebuild behaviours for PlayRun: continuous or on-demand.

If Gradle is run with --continuous (or -t), the application will be rebuilt and reloaded as soon as any file changes are detected. Without the --continuous flag, Gradle will only rebuild the application on-demand, when an HTTP request is received by the application.

In summary:

  1. To start the application, monitor changes, and rebuild/reload the application as soon as a change is detected:

    gradle --continuous runPlay

  2. To start the application, monitor changes, and rebuild/reload the application only when a request is received after a change is detected.

    gradle runPlay

Improved Twirl template support

Gradle now supports the standard built-in Twirl templates for HTML, JavaScript, TXT and XML. These will work out of the box.

Custom Twirl templates are supported: a TwirlSourceSet can now be configured to use these user-defined template formats.

Arbitrary additional imports for packages and classes can also be specified on a a TwirlSourceSet. These will be added to the Scala/Java code generated by the Play Twirl template compiler.

Features for easier plugin authoring

Nested DSL elements

While it is easy for a plugin author to extend the Gradle DSL to add top level blocks to the DSL using project extensions, in previous versions of Gradle it was awkward to create a deeply nested DSL inside these top level blocks, often requiring the use of internal Gradle APIs.

In this release of Gradle, API methods have been added to allow a plugin author to create nested DSL elements. See the example in the user guide section on custom plugins.

Declaring the output of a task as a publish artifact

Plugins use the publish artifacts DSL to declare that a particular file or directory is an output of a project. Gradle then makes these outputs available to other projects, through project dependencies, composite builds or by publishing the project to a Maven or Ivy repository. Usually these outputs are the result of running a particular task. However, in previous versions of Gradle, it was not possible to declare the output of a task as an artifact in a way that handles changes to the build directory and other configuration that is made after the plugin is applied.

In this release, the publish artifact DSL now accepts Provider instances with File, RegularFile or Directory values. This allows a plugin author to easily wire up a particular task output as an artifact in a way that respects later configuration changes. See the ArtifactHandler DSL reference for more details.

Groovy DSL support for properties of type PropertyState

The last several releases of Gradle have added new features for plugin authors that based on the Provider<T> and PropertyState<T> types. This version of Gradle adds some DSL conveniences for working with these types.

The Groovy DSL now adds convenience methods to set the value of a property whose type is PropertyState<T> using any value of T or a Provider<T>. This makes the DSL clearer when configuring such a property, including wiring the output of one task in as the input of some other task or setting output locations relative to some configurable value, such as the build directory. See the example in the user guide.

UX improvements

Gradle 4.2 console

Naming task actions defined with doFirst {} and doLast {}

Task actions that are defined in build scripts can now be named using doFirst("First things first") {} or doLast("One last thing") {}. Gradle uses the names for logging, which allows the user, for example, to see the order in which actions are executed in the task execution views of IDEs. The action names will also be utilised in build scans in the future. This feature is supported in both Kotlin and Groovy build scripts.

Use of color to indicate build status

The current build pass/fail status is indicated as a green or red progress bar during the build, much like you'd see on many CI systems.

CLI abbreviates long test names

In Gradle 4.1, the Gradle CLI began displaying tests in-progress. We received feedback that long packages and test names caused the test name to be truncated or omitted. This version will abbreviate java packages of long test names to 60 characters to make it highly likely to fit on terminal screens.

Safer handling of stale output files

In previous releases, tasks could produce incorrect results when output files were left behind during upgrades or when processes outside of Gradle created files in a shared output directory. Gradle is able to detect these situations and automatically remove stale files, if it is safe to do so. Only files within buildDir, paths registered as targets for the clean task and source set outputs are considered safe to remove.

Connect to untrusted HTTPS build cache

The HTTP build cache connector can now be configured to allow HTTPS connections to servers with untrusted SSL certificates. The SSL certificate for the HTTP build cache server may be untrusted since it is internally provisioned or a self-signed certificate. For more details see the HttpBuildCache.allowUntrustedServer.

Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backward 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.

Fixed issues

Deprecations

Features that have become superseded or irrelevant due to the natural evolution of Gradle become deprecated, and scheduled to be removed in the next major Gradle version (Gradle 5.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 the Gradle Forums.

Java 7 support is deprecated

Support for running Gradle on Java 7 is deprecated and will be removed in Gradle 5.0; Java 7 reached end-of-life in April 2015. However, you will still be able to compile, test, generate Javadoc and execute applications for Java 6 and Java 7 using cross-compilation

We highly recommend migrating to Java 8 as soon as possible to get better experience and support.

Path separator characters in names are deprecated

We deprecated the usage of the following characters in domain object names such as project or task names: space character, /, \\, :, <, >, ", ?, * and |. We also deprecated . as leading or trailing character. These characters represent path separators or have other special semantics in file systems. This caused inconsistent and unexpected behavior in different Gradle features. Using these characters in names will be forbidden in Gradle 5.0.

Potential breaking changes

Removed TaskFilePropertyBuilder.withPathSensitivity and TaskOutputFilePropertyBuilder.withPathSensitivity

These methods where not meant to be used, since Gradle does not allow to customize the PathSensitivity for output files.

Upgraded the bndlib to 3.4.0

Gradle previously used biz.aQute.bnd:biz.aQute.bndlib:3.2.0, which did not support Java 9. Gradle now includes bndlib 3.4.0.

FindBugs plugin does not render analysis progress anymore

As observed by many users the FindBugs plugin renders a lot of progress information by default leading to longer, unmanageable logs. The output behavior changes with this release. By default the FindBugs plugin will render no more analysis progress. If you happen to post-process the output and relied on the pre-4.2 behavior, then you can enable the progressing logging with the property FindBugsExtension.showProgress.

External contributions

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

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

Known issues

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

Gradle 4.2.1 Release Notes