The Gradle team is pleased to bring you Gradle 2.10. This release delivers significant performance improvements for large Native software builds, together with a number of bug fixes and smaller improvements.

Major progress has been made on the Rule-based configuration and Software Model infrastructure. We are excited about the opportunities this work will bring, and the progress that has been made. With full support for dependency management, an improved DSL and better support for developing plugins, the Gradle 2.10 release brings this revolutionary way of building software closer to the mainstream.

New and noteworthy

Here are the new features introduced in this Gradle release.

Performance improvements for native compilation

Gradle needs to know all input properties, input files and output files of a task to perform incremental build checks. When no input or output files have changed, Gradle can skip executing a task.

For native compilation tasks, Gradle used to consider the contents of all include directories as inputs to the task. This had performance problems when there were many include directories or when the project root directory was used as an include directory. To speed up up-to-date checks, Gradle now treats the include path as an input property and only considers those header files that are actually referenced by a source file as a inputs. Our performance benchmarks have demonstrated this to have a large positive impact on incremental builds for very large native projects.

For C++ and related languages, Gradle uses source file parsing to determine the set of included headers for a source file. If Gradle cannot determine the set of included headers, it will fall back to the old mechanism of including all files in all include directories as inputs. This means that using a macro to define an #include file is not recommended, as it can prevent Gradle from taking advantage of this optimization.

TestKit dependency is decoupled from Gradle core classes and dependencies

Declaring a dependency on gradleTestKit() includes all of the Gradle TestKit runtime classpath. In previous versions of Gradle this TestKit dependency also included transitive dependencies on some Gradle core classes and external libraries. This could lead to version conflicts between the TestKit runtime classpath and user-defined dependency declarations.

Gradle TestKit now avoids polluting the runtime classpath by using a fat and shaded JAR file for any required Gradle core classes and external dependencies.

New task for visualising a buildScript dependencies

The new buildEnvironment task can be used to obtain better insight into the buildscript dependencies of a Gradle project. This task is implicitly available for all projects, much like the existing dependencies task.

Use the buildEnvironment task to gain an understanding of how the declared dependencies of project's build script are actually resolved, and to debug issues with plugin loading and classloading.

The feature was kindly contributed by Ethan Hall.

HTML report for Checkstyle

The Checkstyle task now produces a HTML report on failure in addition to the existing XML report. This more human friendly HTML report is generated by default, and when available will be advertised in preference to the XML report.

This feature was kindly contributed by Sebastian Schuberth.

Tooling API exposes Java source language level for Eclipse projects

The Tooling API now exposes the Java source language level that should be used for an Eclipse project via the javaSourceSettings property.

This allows Buildship and other IDE integrations to automatically configure the source language level in Eclipse, so that users no longer need to configure this themselves.

Dependency management for the Java Software Model incubating feature

This release adds some important new features for dependency management for Java libraries in the incubating Java software model.

Component level dependencies for Java libraries In most cases it is more natural and convenient to define dependencies on a component rather than on each of its source sets and it is now possible to do so when defining a Java library in the software model. Example: apply plugin : "jvm-component" model { components { main ( JvmLibrarySpec ) { dependencies { library "core" } } core ( JvmLibrarySpec ) { } } } Dependencies declared this way will apply to all source sets for the component. External dependencies for Java libraries It is now possible to declare dependencies on external modules for a Java library in the software model: repositories { jcenter () } model { components { main ( JvmLibrarySpec ) { dependencies { group 'com.acme' module 'artifact' version '1.0' module 'artifact' group 'com.acme' version '1.0' module 'com.acme:artifact:1.42' } } } } Module dependencies declared this way will be resolved against the configured repositories as usual. External dependencies can be declared for a Java library, Java source set or Java library API specification.

DSL improvements for the Software Model incubating feature

This release includes a number of improvements to the model DSL, which is the DSL you use to define and configure the software model from a build script.

Nested rules in the DSL The ModelMap creation and configuration DSL syntax now defines nested rules, each with its own inputs. For example, this means that an element of a ModelMap can now be configured using the configuration of a sibling as input: model { components { mylib { ... } test { targetPlatform = $ . components . mylib . targetPlatform } } } And because tasks is a ModelMap , this means that a task can be configured using another task as input using the same syntax: model { tasks { jar { ... } dist ( Zip ) { def jar = $ . tasks . jar from jar . output into someDir } } } This is also available for the various methods of ModelMap , such as all or withType : model { components { all { ... } withType ( JvmLibrarySpec ) { ... } } } Configure the properties of a @Managed type The properties of a @Managed type can now be configured using nested configure methods: model { components { mylib { sources { ... } binaries { ... } } } } This is automatically added for any property whose type is @Managed , or a ModelMap<T> or ModelSet<T> . Note that for this release, these nested closures do not define a nested rule, and the closure is executed as soon as it is encountered in the containing closure. This will be improved in the next Gradle release. See the model DSL user guide section for more details and examples. Convenient configuration of scalar properties The model DSL now supports automatic conversions between various scalar types, making it very easy to use one type for another. In particular, you can use a String wherever a scalar type is expected. For example: enum FailType { FAIL_BUILD , WARNING } @ Managed interface CoverageConfiguration { double getMinClassCoverage () void setMinClassCoverage ( double minCoverage ) double getMinPackageCoverage () void setMinPackageCoverage ( double minCoverage ) FailType getFailType () void setFailType ( FailType failType ) File getReportTemplateDir () void setReportTemplateDir ( File templateDir ) } model { coverage { minClassCoverage = '0.7' minPackageCoverage = 1L failType = 'WARNING' templateReportDir = 'src/templates/coverage' } }

Better support for developing plugins with the Software Model

This release includes some major capabilities to allow plugin authors to extend the software model