The Gradle team is excited to announce Gradle 5.5-rc-1.
This release features improvements to build init to generate plugin projects, an API for transforming dependency artifacts, the ability to declare organization-wide Gradle properties, lots of new native plugin documentation and more.
We would like to thank the following community contributors to this release of Gradle:
Switch your build to use Gradle 5.5-rc-1 by updating your wrapper:
./gradlew wrapper --gradle-version=5.5-rc-1
See the Gradle 5.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 5.5-rc-1.
A dependency’s artifacts can take many forms, and sometimes you might need one that is not readily available. As an example, imagine you have a dependency on a Java module. Its producer publishes a normal JAR file and an obfuscated JAR file to a binary repository. As a consumer, you want to use the normal JAR for development. But for production, you want to use an obfuscated version of the JAR rather than the version that’s published.
Let’s say you want to get hold of the obfuscated JAR, but it’s not available in any repository. Why not just retrieve the un-obfuscated JAR and obfuscate it yourself?
Gradle now allows you to register an artifact transform to do just that, by hooking into the dependency management resolution engine. You can specify that whenever an obfuscated JAR is requested but can’t be found, Gradle should run an artifact transform that performs the obfuscation and makes the resulting artifact available transparently to the build.
For more information have a look at the user manual.
init task now provides an option to use Junit Jupiter, instead of Junit 4, to test Java applications and libraries. You can select this test framework when you run the
init task interactively, or use the
--test-framework command-line option. See the User manual for more details.
Contributed by Erhard Pointl
init task can now generate simple Gradle plugin projects. You can use these as a starting point for developing and testing a Gradle plugin. The
init task provides an option to use either Java, Groovy or Kotlin for the plugin source. You can select a Gradle plugin when you run the
init task interactively, or use the
--type command-line option.
See the User manual for more details.
Gradle now looks for a
gradle.properties file in the Gradle distribution used by the build. This file has the lowest precedence of any
gradle.properties and properties defined in other locations will override values defined here.
By placing a
gradle.properties file in a custom Gradle distribution, an organization can add default properties for the entire organization or tweak the default Gradle daemon memory parameters with
The C++ guides have been updated to reflect all the new features available to C++ developers.
See more information about the Gradle native project.
When importing Gradle Eclipse projects into Buildship, the current Eclipse workpace state is taken into account. This allows Gradle to import/synchronize in Eclipse workspaces that include non-Gradle projects that conflict with project names in the imported project.
The upcoming 3.1.1 version of Buildship is required to take advantage of this behavior.
Contributed by Christian Fränkel
The Gradle Kotlin DSL embedded Kotlin compiler has been upgraded from version
1.2.21 to version
1.3.31, please refer to the Kotlin 1.3.30 release blog entry and the Kotlin 1.3.31 GitHub release notes for details.
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.
We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.