The Gradle team is pleased to announce Gradle 4.4.
First and foremost, this release of Gradle features some exciting improvements for IDE users:
vswhere and VS toolchain discovery changes if you plan to use Gradle with VS 2017.eclipse plugin now provides separate output folders. This allows Eclipse plugins to provide more sophisticated classpath management. Buildship 2.2 will take advantage of this feature to avoid one large global classpath when running Java applications or executing tests in Eclipse IDE.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.
mavenCentral() repository URLTest task structureeclipse plugin@Incubating methodspluginManagement.repositories changedHere are the new features introduced in this Gradle release.
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.
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.
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.
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:
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>[3.0,4.0)</version>
</parent>
<groupId>org.apache.maven.its.mng2199</groupId>
<artifactId>valid</artifactId>
<version>1</version>
<packaging>pom</packaging>
</project>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.
This version of Gradle improves the runPlayBinary task to work with Play 2.6.
dist task fixes the generated start scriptYou can read more in the improved Play plugin user guide chapter. Special thanks to Marcos Pereira for extraordinary contributions here.
// settings.gradle
pluginManagement {
repositories {
maven {
name = "My Custom Plugin Repository"
url = "https://..."
}
}
}// settings.gradle
pluginManagement {
repositories {
gradlePluginPortal()
jcenter()
google()
mavenCentral()
}
}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.
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 {
gradlePluginPortal()
}mavenCentral() repository URLIn previous versions of Gradle the URL referred to by RepositoryHandler.mavenCentral() was pointing to https://repo1.maven.org/maven2/. Sonatype recommends using the canonical URL https://repo.maven.apache.org/maven2/ instead. This version of Gradle makes the switch to repo.maven.apache.org when using the mavenCentral() API to avoid SSL errors due to MVNCENTRAL-2870.
In this release, the Gradle team added a new chapter in the user guide documenting the Provider API.
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 annotationPromoted 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.
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.
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.
Test task structureCommon 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.).
eclipse pluginThe default output location in EclipseClasspath changed from ${project.projectDir}/bin to ${project.projectDir}/bin/default.
@Incubating methodsorg.gradle.nativeplatform.tasks.InstallExecutable.setDestinationDir(Provider<? extends Directory>) was removed. Use org.gradle.nativeplatform.tasks.InstallExecutable.getInstallDirectory() instead.org.gradle.nativeplatform.tasks.InstallExecutable.setExecutable(Provider<? extends RegularFile>) was removed. Use org.gradle.nativeplatform.tasks.InstallExecutable.getSourceFile() instead.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.
This version includes several upgrades of third-party dependencies:
jackson: 2.6.6 -> 2.8.9httpclient: 4.4.1 -> 4.5.3plexus-utils: 2.0.6 -> 2.1xercesImpl: 2.9.1 -> 2.11.0bsh: 2.0b4 -> 2.0b6bouncycastle: 1.57 -> 1.58to 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.
Gradle has been upgraded to embed Ant 1.9.9 over Ant 1.9.6.
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.
pluginManagement.repositories changedBefore Gradle 4.4 it was a PluginRepositoriesSpec. This type has been removed and pluginManagement.repositories is now a regular RepositoryHandler.
We would like to thank the following community members for making contributions to this release of Gradle.
ClassLoader (gradle/gradle#3224)We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.
Known issues are problems that were discovered post release that are directly related to changes made in this release.