Gradle Release Notes

Version 1.3

This is a significant release that includes exciting new features and some very important stabilization and optimization, particularly in the area of dependency management.

Our commitment to the Scala language as a first class citizen in the Gradle ecosystem is evident in this release. Through our hardwork, in cooperation with the folks from Typesafe, Gradle now ships with one of the most frequently requested improvements from Scala developers: decreased compile times through incremental compilation. The ability to fork compilation has also been added along with improvements to Eclipse integration for Gradle Scala projects.

As software becomes more and more modular and componentized, development teams are requiring more sophistication and more flexibility in how their built items are published for downstream consumption. This release includes the first step towards a richer and more powerful publication approach within Gradle, that provides the ability to completely customize the Ivy module descriptor created when publishing in the Ivy format.

Dependency management is a critical Gradle function. Many important fixes/optimizations have been made in this release that improve the general dependency management experience in many areas. Along with these improvements, there is an extremely useful new dependency report that can be used to extract precise information from the resolved dependency graph, with regard to a particular dependency. This report is enabled by the powerful new Resolution Result API introduced in Gradle 1.2, that has been further refined in this release. You can expect to see further improvements and innovation in this area in future Gradle versions.

As always, you can share your feedback and experiences with Gradle 1.3 via the Gradle Forums. Please read on for detailed information about this release.

Table Of Contents

New and noteworthy

Here are the new features introduced in this release.

New dependencyInsight report task

The new dependencyInsight report complements the dependencies report (that was improved in Gradle 1.2). Where the dependencies report provides information on the whole dependency graph, the dependencyInsight report focusses on providing information on one (or more) dependencies within the graph.

The report can be used to answer (very common) questions such as:

  • Why is this dependency in the dependency graph?
  • Exactly which dependencies are pulling this dependency into the graph?
  • What is the actual version (i.e. selected version) of the dependency that will be used?
    • Is it the same as what was requested?
  • Why is the selected version of a dependency different to the requested?

The selected version of a dependency can be different to the requested (i.e. user declared) version due to dependency conflict resolution or by explicit dependency force rules. Similar to the standard gradle depenency report, the dependencyInsight report shows both versions. It also shows a requested dynamic version (e.g. “junit:junit:4.+”) together with the actually selected version (e.g. “junit:junit:4.10”). Please keep in mind that Maven snapshot dependencies are not treated as dynamic versions but as changing modules, similar to what Maven does (for the difference see the userguide). Maven snapshots might be treated as dynamic versions in a future version of Gradle which would provide nice insight into pom snapshot resolution.

The dependencyInsight report task is invaluable when investigating how and why a dependency is resolved, and it is available in all projects out of the box.

Incremental Scala compilation

Due to the sophistication of the language and type system, Scala programs can take a long time to compile. Gradle 1.3 addresses this problem by integrating with Zinc, a standalone version of sbt's incremental Scala compiler. By compiling only classes whose source code has changed since the previous compilation, and classes affected by these changes, Zinc can significantly reduce Scala compilation time. It is particularly effective when frequently compiling small code increments, as is often done at development time.

To switch the ScalaCompile task from the default Ant based compiler to the new Zinc based compiler, use scalaCompileOptions.useAnt = false. Except where noted in the API documentation, the Zinc based compiler supports exactly the same configuration options as the Ant based compiler.

Just like the Ant based compiler, the Zinc based compiler supports joint compilation of Java and Scala code. By default, all Java and Scala code under src/main/scala will participate in joint compilation. With the Zinc based compiler, even Java code will be compiled incrementally.

To learn more about incremental Scala compilation, see the Scala plugin chapter in the Gradle User Guide.

Scala compilation in external process

Scala compilation can now be performed outside the Gradle JVM in a dedicated compiler process, which can help to deal with memory issues.

External compilation is supported both for the existing Ant-based and the new Zinc-based Scala compiler. The API is very similar to that for Java and Groovy: ScalaCompile.fork = true activates external compilation, and ScalaCompile.forkOptions allows to adjust memory settings.

Improved Scala IDE integration

The Eclipse Plugin now automatically excludes dependencies already provided by the 'Scala Library' class path container. This improvement is essential for Scala IDE to work correctly. It also takes effect when using the Eclipse Gradle Integration.

Dependency management improvements

With this release of Gradle, we have continued to improve our dependency management implementation. The focus for these improvements in Gradle 1.3 is on stability and this release includes a number of important fixes.

Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to the backwards compatibility policy.

Improved test logging APIs

Gradle 1.1 introduced much improved test logging output. The APIs that provided the ability to configure this logging were introduced in the incubating state. In this Gradle release, these APIs are being promoted and are no longer subject to change without notice.

For more information on the test logging functionality, see this forum post that introduced the feature.

Fixed issues

The list of issues fixed between 1.2 and 1.3 can be found here.

Incubating features

New features as typically introduced as “incubating”. The key characteristic of an incubating feature is that it may change in an incompatible way in a future Gradle release. At some time in the future, after incorporating invaluable real-world feedback from Gradle users, the feature will be deemed stable and “promoted”. At this point it is no longer subject to incompatible change. That is, the feature is now subject to the backwards compatibility policy.

Typically, the implementation quality of incubating features is sound. For some very challenging engineering problems, such as the Gradle Daemon or parallel task execution, it is impossible to get the implementation quality right from the beginning as the feature needs real world exposure. The feedback from the incubation phase can be used to iteratively improve the stability of the feature.

By releasing features early in the incubating state, users gain a competitive advantage through early access to new functionality in exchange for helping refine it over time, ultimately making Gradle a better tool.

To learn more, see the User Guide chapter on the Feature Lifecycle.

New Ivy publishing mechanism

This release introduces a new mechanism for publishing to Ivy repositories in the Ivy format. It also introduces some new general publishing constructs. This new publishing support is incubating and will co-exist with the existing methods for publication until the time where it supersedes it, at which point the old mechanism will become deprecated. The functionality included in this release is the first step down the path of providing a better solution for sharing the artifacts built in your Gradle builds.

In this release, we have focussed on laying the groundwork and providing the ability to modify the Ivy module descriptor that is published during a publish operation. It has long been possible to fully customise the pom.xml when publishing in the Maven format; it is now possible to do the same when publishing in the Ivy format.

Improved TestNG HTML report

Gradle has long shipped with HTML report functionality for JUnit test results that improves on the Ant default. It is now possible to use the same HTML report format for TestNG test results. See the reports generated by the Gradle automated builds as an example of the new improved report.

The reports are not yet turned on by default. To enable the new TestNG test reports, simply set testReport = true on your test task.

Note: The new report might exhibit increased heap usage for tests that log many messages to the standard streams. You can increase the heap allocated to the test process via the jvmArgs property of the test task.

Deprecations

Ant-task based Java compiler integration

Gradle currently supports two different Java compiler integrations: A native Gradle integration that uses the compiler APIs directly, and an Ant-task based implementation that uses the <javac> Ant task. The native Gradle integration has been the default since Gradle 1.0-milestone-9. Some of its advantages are:

  • Faster compilation
  • Can run in Gradle compiler daemon (external process that is reused between tasks)
  • More amenable to future enhancements

The Ant-task based integration has now been deprecated and will be removed in Gradle 2.0. As a result, the following properties of CompileOptions are also deprecated and will be removed in Gradle 2.0:

  • useAnt
  • optimize
  • includeJavaRuntime

Ant-task based Groovy compiler integration

Gradle currently supports two different Groovy compiler integrations: A native Gradle integration that uses the compiler APIs directly, and an Ant-task based implementation that uses the <groovyc> Ant task. The native Gradle integration has been the default since Gradle 1.0. Some of its advantages are:

  • Faster compilation
  • Correct handling of AST transformations
  • Can run in Gradle compiler daemon (external process that is reused between tasks)
  • More amenable to future enhancements

The Ant-task based integration has now been deprecated and will be removed in Gradle 2.0. As a result, the following properties of GroovyCompileOptions are also deprecated and will be removed in Gradle 2.0:

  • useAnt
  • stacktrace
  • includeJavaRuntime

Changing the name of a repository once added to a repository container

The ArtifactRepository type has a setName(String) method that you could use to change the repository name after it has been created. Doing so has been deprecated. The name of the repository should be specified at creation time via the DSL.

For example:

repositories {
    ivy {
        name "my-ivy-repo"
    }
}

// The following is now deprecated
repositories.ivy.name = "changed-name"

A deprecation warning will be issued if a name change is attempted. It has been deprecated because changing the name of a repository after it has been added to the container can cause problems when tasks are automatically created for created repositories.

Changes to existing incubating features

Resolution result API

The entry point to the ResolutionResult API has changed. You now access the ResolutionResult via configuration.incoming.resolutionResult. New convenience methods were also added to the API. For more information please refer to the javadoc for ResolutionResult.

Incubating C++ Compile task type removed

This was replaced by CppCompile in Gradle 1.2. You should use the replacement class instead.

Incubating GppCompileSpec properties removed

The deprecated task property was removed from GppCompileSpec.

Potential breaking changes

The behavior of Test.testReport property for TestNG

The default value of the testReport property value of Test tasks has been changed to false for TestNG. Previously, this property was ignored when running with TestNG - the html results were generated regardless.

This property now enables/disables the new improved TestNG report introduced in this release.

Removed GraphvizReportRenderer

This was an early contribution that did not work and was an undocumented private type.

Removed org.gradle.api.publication package

This package contained some early experiments in a new publication model. It was incomplete and undocumented. It is superseded by the new publishing functionality introduced in this release, so has been removed.

Community contributions

We would like to thank the following community members for making contributions to this release of Gradle.

  • Matt Khan - fixed resetting of test.debug to false when using test.jvmArgs (GRADLE-2485)
  • Gerd Aschemann - fixes for application plugins generated shell scripts (GRADLE-2501)
  • Cruz Fernandez - fixes to the properties sample project
  • Fadeev Alexandr - fixes for Gradle Daemon on Win 7 when PATH env var is not set (GRADLE-2461)
  • Ben Manes - improved Scala IDE integration (pull request #99)

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