Gradle 5.5-20190702033235+0000 Release Notes

# Gradle Release Notes

### Version 5.5-20190702033235+0000

The Gradle team is excited to announce Gradle 5.5-20190702033235+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:

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.

## Table Of Contents

## Upgrade Instructions

Switch your build to use Gradle 5.5-20190702033235+0000 by updating your wrapper:

`./gradlew wrapper --gradle-version=5.5-20190702033235+0000`

See the Gradle 5.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 5.5-20190702033235+0000.

## Transforming dependency artifacts on resolution

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.

## Build init plugin improvements

### Support for JUnit Jupiter

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

### Generate Gradle plugin builds

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.

## Define organization-wide properties with a custom Gradle Distribution

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`.

## Improvements for plugin authors

### Abstract service injection methods

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 collections

Gradle 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.

### Abstract model properties

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.

### Additional documentation

There is a new user manual chapter that describes how to use these features in your custom Gradle types.

## Building native software with Gradle

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.

## Improved Eclipse project name deduplication in Buildship

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

## Gradle Kotlin DSL compiler upgraded to Kotlin 1.3.31

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.

## Fixed issues

## Known issues

Known issues are problems that were discovered post release that are directly related to changes made in this release.

## External contributions

We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.

## Reporting Problems

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.