The Gradle team is pleased to announce Gradle 4.10. This is a big release.
First and foremost, this release of Gradle features an improved incremental Java compiler, now enabled by default. This will result in significantly reduced Java compilation time in subsequent builds when outputs are not up-to-date or resolved from the build cache.
Chances are caches in those .gradle/ directories have accumulated a few (or a few dozen) gigabytes over time. If so, you'll be relieved to know that Gradle will now periodically clean up unused /caches under GRADLE_USER_HOME and project root directories.
A moment you have anticipated is nearly here, as the Kotlin DSL reaches version 1.0 RC3. Configuration avoidance, buildSrc refactoring propagation to the IDE, and lots of DSL polish make this the release to try. Gradle Kotlin DSL 1.0 will ship with the next version of Gradle. Please give it a go and file issues in the gradle/kotlin-dsl project. If you are interested in using the Kotlin DSL, please check out the Gradle guides, especially the Groovy DSL to Kotlin DSL migration guide.
You can now use SNAPSHOT plugin versions with the plugins {} and pluginManagement {} blocks. This is especially good news for Kotlin DSL users, who will get code assistance and auto-completion for these SNAPSHOT plugins. Special thanks to Sébastien Deleuze for contributing.
Last but not least, included builds can now be nested. This makes some common workflows more convenient, such as working on multiple source repositories at the same time to implement a cross-cutting feature.
We hope you will build happiness with Gradle 4.10, and we look forward to your feedback via Twitter or on GitHub.
Switch your build to use Gradle 4.10 quickly by updating your wrapper properties:
./gradlew wrapper --gradle-version=4.10Standalone downloads are available at gradle.org/releases.
Here are the new features introduced in this Gradle release.
This release fixes all known issues of the incremental compiler. It now
Its memory usage has also been reduced. For the gradle/gradle build, heap usage dropped from 350MB to just 10MB.
We are now confident that the incremental compiler is ready to be used in every build, so it is now the new default setting.
Caching has always been one of the strong suits of Gradle. Over time, more and more persistent caches have been added to improve performance and support new features, requiring more and more disk space on build servers and developer workstations. Gradle now addresses one of the most highly voted issues on GitHub and introduces the cleanup strategies for the caches in the Gradle user home directory and the project root directory.
plugins {} blockStarting with this release, it is now possible to use SNAPSHOT plugin versions in the plugins {} and pluginManagement {} blocks. For example:
plugins {
id 'org.springframework.boot' version '2.0.0.BUILD-SNAPSHOT'
}Composite builds is a feature that allows a Gradle build to 'include' another build and conveniently use its outputs locally rather than via a binary repository. This makes some common workflows more convenient, such as working on multiple source repositories at the same time to implement a cross-cutting feature. In previous releases, it was not possible for a Gradle build to include another build that also includes other builds, which limits the usefulness of this feature for these workflows. In this Gradle release, a build can now include another build that also includes other builds. In other words, composite builds can now be nested.
There are a number of limitations to be aware of. These will be improved in later Gradle releases:
buildSrc build cannot include other builds, such as a shared plugin build.Now it is possible to define a custom HTTP header to authorize access to a Maven repository. This enables Gradle to access private Gitlab and TFS repositories used as Maven repositories or any OAuth2 protected Maven repositories.
Early previews of Java 9 failed when Gradle tried to update the environment variables of the daemon to match the client that requested the build. The final Java 9 version added ways to work around this, but Gradle was not updated accordingly, meaning that environment variables always had the same value as when the daemon was started. This has now been fixed and the environment variables of the daemon will match the variables of the client again. Changes to the PATH will be visible to Exec tasks and calling System.getenv will yield the expected result.
However, we strongly recommend that build and plugin authors use Gradle properties instead of System.getenv for a more idiomatic end user experience.
Memory usage for up-to-date checking has been improved. For the gradle/gradle build, heap usage dropped by 60 MB to 450 MB, that is a 12% reduction.
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.
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.
Instances of this class are intended to be created only by the java-base plugin and should not be created directly. Creating instances using the constructor of JavaPluginConvention will become an error in Gradle 5.0. The class itself is not deprecated and it is still be possible to use the instances created by the java-base plugin.
Instances of this class are intended to be created only by the application plugin and should not be created directly. Creating instances using the constructor of ApplicationPluginConvention will become an error in Gradle 5.0. The class itself is not deprecated and it is still be possible to use the instances created by the application plugin.
Instances of this class are intended to be created only by the war plugin and should not be created directly. Creating instances using the constructor of WarPluginConvention will become an error in Gradle 5.0. The class itself is not deprecated and it is still be possible to use the instances created by the war plugin.
Instances of this class are intended to be created only by the ear plugin and should not be created directly. Creating instances using the constructor of EarPluginConvention will become an error in Gradle 5.0. The class itself is not deprecated and it is still be possible to use the instances created by the ear plugin.
Instances of this class are intended to be created only by the base plugin and should not be created directly. Creating instances using the constructor of BasePluginConvention will become an error in Gradle 5.0. The class itself is not deprecated and it is still be possible to use the instances created by the base plugin.
Instances of this class are intended to be created only by the project-reports plugin and should not be created directly. Creating instances using the constructor of ProjectReportsPluginConvention will become an error in Gradle 5.0. The class itself is not deprecated and it is still be possible to use the instances created by the project-reports plugin.
These methods have been deprecated and the create() or register() methods should be used instead.
The Kotlin DSL enables experimental Kotlin compiler features in order to expose an uniform org.gradle.api.Action<T> based API to both Groovy DSL and Kotlin DSL scripts.
The DSL types and behavior of containers elements delegated properties (e.g. val jar by tasks) and containers scopes (e.g. tasks { }) changed.
The source set container can now be accessed using project.sourceSets, or just sourceSets. Previously it was located at project.java.sourceSets, or just java.sourceSets.
All these changes could cause script compilation errors.
See the Gradle Kotlin DSL release notes for more information and how to fix builds broken by the changes described above.
In Gradle 4.9, we introduced a new API for creating and configuring tasks.
The following hooks are disallowed when called from these new APIs:
project.afterEvaluate(Action) and project.afterEvaluate(Closure)project.beforeEvaluate(Action) and project.beforeEvaluate(Closure)If you attempt to call any of these methods an exception will be thrown. Gradle restricts these APIs because mixing these APIs with lazy configuration can cause hard to diagnose build failures and complexity.
The S3 repository transport protocol allows Gradle to publish artifacts to AWS S3 buckets. Starting with this release, every artifact uploaded to an S3 bucket will be equipped with bucket-owner-full-control canned ACL. Make sure the used AWS credentials can do s3:PutObjectAcl and s3:PutObjectVersionAcl to ensure successful artifacts uploads.
{
"Version":"2012-10-17",
"Statement":[
// ...
{
"Effect":"Allow",
"Action":[
"s3:PutObject", // necessary for uploading objects
"s3:PutObjectAcl", // required starting with this release
"s3:PutObjectVersionAcl" // if S3 bucket versioning is enabled
],
"Resource":"arn:aws:s3:::myCompanyBucket/*"
}
]
}See the User guide section on “Repository Types” for more information.
PluginUnderTestMetadata and GeneratePluginDescriptors were updated to use the Provider API.set(...) method.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.
plugins {} block (gradle/gradle#5762)RegularFile and Directory as publishable artifacts (gradle/gradle#5109)java-gradle-plugin to use lazy configuration API (gradle/gradle#6115)Known issues are problems that were discovered post release that are directly related to changes made in this release.