The Gradle team is excited to announce Gradle 5.2.
This release features a new Java Platform plugin, improved C++ plugins, new C++ project types for
gradle init, service injection into plugins and project extensions, Kotlin DSL 1.1.3 and more.
Read the Gradle 5.x upgrade guide to learn about breaking changes and considerations for upgrading from Gradle 5.0. If upgrading from Gradle 4.x, please read upgrading from Gradle 4.x to 5.0 first. Users upgrading from 5.1 should not have to worry about breaking changes.
We would like to thank the following community contributors to this release of Gradle:
Thomas Broyer, Szczepan Faber, Stefan M., Kim Brouer, Roberto Perez Alcolea, Ian Kerins, Josh Soref, Andrew Nessin, NFM, Jean-Michel Fayard, Arun Ponniah Sethuramalingam, Victor Jacobs, Theodore Ni, Sam Holmes, Artem Zinnatullin, Ronald Brindl, and Richard Newton.
Switch your build to use Gradle 5.2 by updating your wrapper properties:
./gradlew wrapper --gradle-version=5.2
Standalone downloads are available at gradle.org/releases.
This release features the Java Platform plugin, which allows you to declare a platform. Like Maven BOMs, platforms can be used to define a set of versions for dependencies that are known to work together. These versions can be published and consumed elsewhere as dependency recommendations.
Read the Java Platform plugin section of the userguide for more details.
See more information about the Gradle native project.
We introduced new C++ plugins last year that are more feature rich and familiar to Gradle users.
In this release, we are recommending new C++ projects use these plugins over the existing software model plugins. The new plugins do not currently support C, Objective-C or Objective-C++ out of the box, but they have a lot of other things to offer.
If you want to get started quickly with a C++ project, try running
gradle init and following the instructions to generate a sample C++ application or library. You'll notice that the projects will be generated with the
cpp-library plugins instead of the
cpp plugin. This is now the recommended approach when starting new projects.
In previous versions of Gradle, native builds using GCC with cygwin64 or mingw64 was reported to work, but was not officially supported. These toolchains are now officially supported by Gradle. See the userguide for more information about supported native toolchains.
Gradle now automatically hides the
main symbol when building native applications, so applications can be tested on Windows like they already were on macOS and Linux.
Contributed by Richard Newton.
There are several useful services that Gradle makes available for task and plugin implementations to use. Previously, these were available for injection into task and plugin instances. In this Gradle release these services are also available for injection directly into project extensions. Services are also now available for injection into the elements of a container created using the
project.container(Class) method. Using this feature can help simplify your plugin implementation.
Services can be injected into an instance either as constructor parameters or using a property getter method. In this release both options are available for all types for which service injection is available. In previous Gradle versions, using a property getter method was not supported for plugin types.
See the user manual sections on service injection for plugins and service injection into tasks for details.
Gradle TestKit based tests can now specify environment variables via
GradleRunner. These environment variables will be visible to the build under test.
Contributed by Szczepan Faber.
When using the
maven-publish plugin, you can now opt-in to publish the resolved dependency versions instead of the declared ones. For details, have a look at the dedicated section in the plugin documentation.
This release includes some improvements to Gradle's console integration on Windows. Gradle now detects when it is running from Mintty on Windows and enables the rich console. Mintty is a popular terminal emulator used by projects such as Cygwin and Git for Windows.
The implementation of the rich console has been improved to remove some distracting visual artifacts on Windows.
Sources generated by annotation processors are now put in a separate directory by default, which means they will no longer pollute your production jar file.
Due to a bug in javac, users would often get warnings about unrecognized processor options during incremental compilation, because the corresponding processor did not need to run. This warning is now fixed and will only appear if an option is really unrecognized.
Contributed by Thomas Broyer.
JavaExectasks track the version of Java used
Tasks that use
JavaExec now track the version of Java used instead of the absolute path to the
Contributed by Theodore Ni.
Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility. See the User manual section on the “Feature Lifecycle” for more information.
The following are the features that have been promoted in this Gradle release.
Known issues are problems that were discovered post release that are directly related to changes made in this 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 6.0). See the User Manual 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 default constructor of
ProjectBuilder is now deprecated. You should always use
ProjectBuilder#builder() to create instances.
See the Gradle 5.x upgrade guide to learn about breaking changes and considerations for upgrading from Gradle 5.x.
We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.
If you find a problem with this release, please file a bug on GitHub Issues adhering to our issue guidelines. If you're not sure you're encountering a bug, please use the forum.
We hope you will build happiness with Gradle, and we look forward to your feedback via Twitter or on GitHub.