The Gradle team is excited to announce Gradle 5.5.1-20190724234647+0000.
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:
Dan Sănduleac, Martin d'Anjou, Ben Asher, Mike Kobit, Erhard Pointl, Sebastian Schuberth, Evgeny Mandrikov, Stefan M., Igor Melnichenko, Björn Kautler, Roberto Perez Alcolea and Christian Fränkel.
Switch your build to use Gradle 5.5.1-20190724234647+0000 by updating your wrapper:
./gradlew wrapper --gradle-version=5.5.1-20190724234647+0000
See the Gradle 5.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 5.5.1-20190724234647+0000.
NOTE: Gradle 5.5 has had one patch release. We recommend using the latest patch release.
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.
The 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
The 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 org.gradle.jvmargs.
Gradle provides several useful services that are available for injection into various custom types, including task types, plugins and project extensions. One such service, for example, is the
ObjectFactory type.
In previous Gradle versions, a type could receive a service by declaring a property getter with a dummy method body. Now, these property getters can be abstract, which is more convenient and clearer.
See the user manual for more details and examples.
ObjectFactory methods for creating domain object collectionsGradle provides a number of types that plugin authors can use to manage a collection of objects. These are called the "domain object collection" types and provide useful features such as DSL support and lazy configuration. These types are used extensively throughout the Gradle API, for example project.tasks and project.repositories are domain object collections.
Previously, it was only possible to create a domain object collection by using the APIs provided by a Project. However, a Project object is not always available, for example in a Settings plugin or in a project extension object.
The ObjectFactory service now has methods for creating NamedDomainObjectContainer and DomainObjectSet instances. This means that any code where a ObjectFactory is available can now create collection instances.
See the user manual for more details and examples.
A custom type, such as a task type, plugin or project extension can now be implemented as an abstract class or, in the case of project extensions and other data types, an interface. Gradle can provide an implementation for abstract properties.
For a property with abstract getter and setter methods, Gradle will provide implementations for the getter and setters.
For a read only property with an abstract getter method, Gradle will provide an implementation for the getter method and also create a value for the property. For plugin authors, this simplifies the process of providing configuration properties for a task or project extension.
See the user manual for more details and examples.
There is a new user manual chapter that describes how to use these features in your custom Gradle types.
Gradle's user manual now includes new chapters for building and testing C++ projects. The DSL guide now includes C++ related types.
Reference chapters were also created for all of the C++ plugins and Visual Studio and Xcode IDE plugins.
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.
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.
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.