Gradle Release Notes

Version 4.4.1

The Gradle team is pleased to announce Gradle 4.4.

First and foremost, this release of Gradle features some exciting improvements for IDE users:

Editing a Gradle Build for a C++ Library in Visual Studio 2017

No discussion about IDE support for Gradle would be complete without mentioning improvements to the Kotlin DSL. Version 0.13 is included in Gradle 4.4 and provides support for writing settings.gradle.kts files, Kotlin standard library extensions to the Java 7 and Java 8 APIs for use in build scripts, improvements to the plugins {} DSL, and more! See the Kotlin DSL 0.13 release notes for more details.

This version of Gradle supports version ranges in parent elements of a POM. You can see an example below.

C and C++ developers will enjoy better incremental builds and build cache support for C/C++ because this version of Gradle takes compiler version and system headers into account for up-to-date checks.

This version of Gradle fully supports the combination of Play 2.6 and Scala 2.12, with improvements and fixes to runPlayBinary, the distributed Play start script, and other improvements.

Previous versions of Gradle required that all transitive dependencies of a given plugin were present in the same repository as the plugin. Gradle 4.4 takes all plugin repositories into account and can resolve transitive plugin dependencies across them. Learn about this and other plugin repository handling improvements in the details.

Last but not least, several 3rd party dependencies including Ant were updated to their latest versions containing security and other bug fixes.

Table Of Contents

New and noteworthy

Here are the new features introduced in this Gradle release.

Eclipse plugin separates output folders

The eclipse plugin now defines separate output directories for each source folder. This ensures that main and test classes are compiled to different directories.

The plugin also records which Eclipse classpath entries are needed for running classes from each source folder through the new gradle_scope and gradle_used_by_scope attributes. Future Buildship versions will use this information to provide a more accurate classpath when launching applications and tests.

Visual Studio 2017 support

It is now possible to compile native applications with the Visual C++ toolchain packaged with all versions of Visual Studio 2017. Note that discovery of a Visual Studio 2017 installation requires the vswhere utility. Visual Studio 2017 versions earlier than update 2 do not install vswhere automatically, and so to use one of these earlier versions of Visual Studio 2017 when vswhere is not installed, you'll need to set the installation directory on the VisualCpp toolchain.

Parametrized tooling model builders

The Tooling API now allows model builders to accept parameters from the tooling client. This is useful when there are multiple possible mappings from the Gradle project to the tooling model and the decision depends on some user-provided value.

Android Studio, for instance, will use this API to request just the dependencies for the variant that the user currently selected in the UI. This will greatly reduce synchronization times.

For more information see the documentation of the new API.

Support version ranges in parent elements

When resolving an external dependency from Maven repository, Gradle now supports version ranges in a parent element of a POM, which was introduced by Maven 3.2.2. The following is now permissible:


C/C++ incremental build improvements

C/C++ compilation now takes system headers, and the compiler vendor and version into account, making it safer to use those tasks with incremental build and experimental native caching.

Before Gradle 4.4 changing the compiler did not make the compilation task out of date, even though different compilers may produce different outputs. Changing system headers were not detected either, so updating a system library would not have caused recompilation.

Improved Play 2.6 support

This version of Gradle improves the runPlayBinary task to work with Play 2.6.

You can read more in the improved Play plugin user guide chapter. Special thanks to Marcos Pereira for extraordinary contributions here.

Plugin repositories enhancements

Plugin repositories declared in a settings script can now have custom names

// settings.gradle
pluginManagement {
    repositories {
        maven {
            name = "My Custom Plugin Repository"
            url = "https://..."

Explicit notation for common repositories can now be used in settings scripts:

// settings.gradle
pluginManagement {
    repositories {

Gradle Plugin resolution changes

Plugin resolution now takes all plugin repositories into account and can resolve transitive plugin dependencies across them. Previous versions of Gradle required that all transitive dependencies of a given plugin were present in the same repository as the plugin.

Build scripts can declare Gradle Plugin Portal

Finally, the Gradle Plugin Portal repository can now be added to build scripts. This is particularly useful for buildSrc or binary plugin builds:

// build.gradle
repositories {

Use of canonical URL for mavenCentral() repository URL

In previous versions of Gradle the URL referred to by RepositoryHandler.mavenCentral() was pointing to Sonatype recommends using the canonical URL instead. This version of Gradle makes the switch to when using the mavenCentral() API to avoid SSL errors due to MVNCENTRAL-2870.

Provider API documentation

In this release, the Gradle team added a new chapter in the user guide documenting the Provider API.

Task validation disallows input/output annotations on private getters

Annotating private task properties will not be allowed in Gradle 5.0. To prepare for this, Gradle 4.4 will warn about annotations on private properties. The warning is visible when building the task with the java-gradle-plugin applied:

Task property validation finished with warnings:
- Warning: Task type 'MyTask': property 'inputFile' is private and annotated with an input or output annotation

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.

Fixed issues


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.

Deprecation of no-rebuild command line options

The command line options for avoiding a full rebuild of dependent projects in a multi-project builds (-a/--no-rebuild) were introduced in a very early version of Gradle. Since then Gradle optimized its up-to-date checking for project dependencies which renders the option obsolete. It has been deprecated and will be removed in Gradle 5.0.

Potential breaking changes

Change to the Test task structure

Common test framework functionality in the Test task moved to AbstractTestTask. Be aware that AbstractTestTask is the new base class for the Test task. The AbstractTestTask will be used by test frameworks outside of the JVM ecosystem. Plugins configuring an AbstractTestTask will find tasks for test frameworks (e.g., XCTest, Google Test, etc.).

Changes in the eclipse plugin

The default output location in EclipseClasspath changed from ${project.projectDir}/bin to ${project.projectDir}/bin/default.

Removal of @Incubating methods

Changes to Visual Studio toolchain discovery

In previous versions, Gradle would prefer a version of Visual Studio found on the path over versions discovered through any other means. It will now consider a version found on the path only if a version is not found in the registry or through executing the vswhere utility (i.e. it will consider the path only as a last resort). In order to force a particular version of Visual Studio to be used, configure the installation directory on the Visual Studio toolchain.

Upgrade of third-party dependencies

This version includes several upgrades of third-party dependencies:

to fix the following security issues:

Gradle does not expose public APIs for these 3rd-party dependencies, but those who customize Gradle will want to be aware.

Ant version upgraded to Ant 1.9.9

Gradle has been upgraded to embed Ant 1.9.9 over Ant 1.9.6.

Avoid checking other repositories when dependency resolution in one repository fails with HTTP status code in the 500 range

The HTTP status codes 5xx can be considered unrecoverable server states. Gradle will explicitly rethrow exceptions which occur in dependency resolution instead of quietly continue to the next repository similar to timeout issues introduced in Gradle 4.3.

The type of pluginManagement.repositories changed

Before Gradle 4.4 it was a PluginRepositoriesSpec. This type has been removed and pluginManagement.repositories is now a regular RepositoryHandler.

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

Known issues

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