Gradle Release Notes

Version 3.0-milestone-2

The Gradle team is pleased to announce Gradle 3.0 M2.

This second release leading up to Gradle 3.0 builds on 3.0 M1 with several key improvements listed below. For more information, see the announcement blog post.

Check out some of the improvements we've made since Gradle 2.0. Lots of reasons to upgrade!

Table Of Contents

Compatibility and Support

This release is intended as a preview for new features we'll be releasing soon in Gradle 3.0. As such, it is not intended to be used in a production environment and features may change significantly before they are released in Gradle 3.0.

New and noteworthy

Here are the new features introduced in this Gradle release.

New Features and Improvements since 3.0 M1

Improved Gradle Daemon, now enabled by default

The performance improvement gained by using the Daemon is staggering: our performance tests show that builds could be up to 75% faster, just by enabling the Gradle Daemon.

We have been working hard to make the Gradle Daemon aware of its health and impact on the system it's running on; and we believe that it is now robust enough to be enabled by default.

We encourage you to give the improved Daemon a try. If for some reason you encounter problems, you can disable the Daemon. Please submit feedback to us if you encounter instability so that we can make further improvements.

List Running Gradle Daemons with gradle --status

You can now check the status of running Daemons. A sample:

$> gradle --status PID VERSION STATUS 28411 3.0 IDLE 34247 3.0 BUSY

Note that currently this does not list Gradle Daemons with version < 3.0. More details available in the User Guide.

Up-to-date checks more robust against task implementation changes

Previously if a task's implementation class name changed, the class was deemed out-of-date even if its inputs and outputs matched the previous execution. However, if only the code of the task, or a dependent library changed, the task was still considered up-to-date. Since this version Gradle notices if the code of a task or its dependencies change between executions, and marks tasks as out-of-date when needed.

plugins DSL can resolve plugins without applying them

There are times when you want to resolve a plugin without actually applying it to the current project, e.g.

This is now possible using the following syntax

``` plugins { id 'my.special.plugin' version '1.0' apply false }

subprojects { if (someCondition) { apply plugin 'my.special.plugin' } }


Improved handling of external dependencies in eclipse-wtp plugin

Before Gradle 3.0, the eclipse-wtp plugin always defined external dependencies the WTP component descriptor. This caused several problems, listed at GRADLE-2123. To resolve this, the plugin now defines external dependencies in the Eclipse classpath and marks them as deployed/non-deployed accordingly. For each library a classpath entry similar to the one below is generated:

<classpathentry kind="lib" path=/path/to/lib-1.0.0.jar" exported=“false">
        <attribute name="org.eclipse.jst.component.dependency" value="WEB-INF/lib"/>

If the project is not a Java project (and thus has no classpath), the dependencies are added to the component descriptor as before.

Improved dependency resolution for eclipse-wtp plugin

The eclipse-wtp plugin now fully leverages Gradle's dependency resolution engine. As a result, all dependency customisations like substitution rules and forced versions work in WTP projects.

eclipse plugin also applies eclipse-wtp for web projects

If a project applies the war or ear plugins, then applying the eclipse plugin also applies eclipse-wtp. This improves the out-of-the box experience for Eclipse Buildship users.

Tooling API exposes more information via the EclipseProject model.

The EclipseProject model was supplemented with a set of new features:

With these features Tooling API clients can provide a more complete IDE integration. Buildship will make use of them very soon.

Initial Java 9 support

Gradle 3.0 contains initial support for Java 9. This means that running Gradle on Java 9 and compiling, testing and running Java 9 applications is supported out of the box.

CAVEAT: Your mileage my vary. If you run into any problems please report those on the forums.

Upgrade of BND library used by OSGi plugin

The OSGi plugin now uses the version 3.2.0 of the BND library.

Improvements since Gradle 2.0

  • Performance improvements, faster builds and reduced memory usage
    • Configuration time, incremental build, incremental native compilation, build script compilation, test execution
  • Gradle plugin portal
    • Publishing plugin
    • Maven and Ivy plugin repositories
  • Dependency management
    • Compile-only dependencies for Java projects
    • Improved component meta-data rules
    • Component selection rules
    • Component replacement rules
    • Dependency substitution rules
    • Support for S3 repositories
    • Configurable HTTP authentication, including preemptive HTTP authentication
    • Artifact query API access to ivy.xml and pom.xml
    • Depend on a particular Maven snapshot
  • Daemon
    • Health and performance monitoring
    • Proactive resource awareness and action
    • List running Daemons
  • Continuous build
  • Incremental Java compile
  • Tooling API
    • Composite builds
    • Rich test, task and build progress events
    • Run test classes or methods
    • Cancellation
    • Color output
    • Eclipse builders and natures, Java source and runtime version, build JDK
  • IDE
    • Improved Eclipse WTP integration, Scala integration
    • Java source and runtime version
  • TestKit
  • publish plugins
    • Publish to SFTP and S3 repositories
    • Maven dependency exclusions, dependency classifiers
    • Ivy extra attributes, dependency exclusions
  • Groovy annotation processing
  • Build environment report
  • Code quality and application plugins
    • Various improvements
  • Native
    • Parallel compilation
    • Cross compilation
    • Precompiled headers
    • Google test support
  • Community
    • More frequent releases
    • More pull requests
  • Play support
  • Text resources
  • Software model
    • Dependency management for JVM libraries, target platform aware
      • inter-project, intra-project and external libraries
    • JVM library API definition, compile avoidance
    • JUnit support
    • Components report, model report
    • Validation and defaults rules, apply rules to all subjects with type
    • More managed model features
    • Better extension by plugins
    • Model DSL

Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility. See the User guide section on the “Feature Lifecycle” for more information.

The following are the features that have been promoted in this Gradle release.

Fixed issues


Features that have become superseded or irrelevant due to the natural evolution of Gradle become deprecated, and scheduled to be removed in the next major Gradle version (Gradle 4.0). See the User guide section on the “Feature Lifecycle” for more information.

The following are the newly deprecated items in this Gradle release. If you have concerns about a deprecation, please raise it via the Gradle Forums.

Plural task output registration APIs

The @OutputFiles and @OutputDirectories annotations support only properties with a Map type, where the values in the map can be resolved to individual files, while the keys represent unique identifiers for each file. Using either of the annotations with an Iterable<File> or FileCollection property is deprecated.

The following APIs have been deprecated:

TaskOutputs.files() method is now deprecated. Use either of the new TaskOutputs.namedFiles() methods instead.

Potential breaking changes

Running Gradle on Java 6 is no longer supported.

Gradle itself now requires Java 7 or better to run, but compiling project sources and running tests with Java 6 remains supported. See Compiling and testing for Java 6 in the Userguide. There are also instructions on how to compile and test Groovy and Scala for Java 6.

Support for compiling and testing on Java 5 has been dropped.

Sonar plugin has been removed

The legacy Sonar plugin has been removed from the distribution. It is superceded by the official plugin from SonarQube (

Ant-Based Scala Compiler has been removed

The deprecated Ant-Based Scala Compiler has been removed from Gradle 3.0. The Zinc Scala Compiler is now used exclusively. The following properties have been removed from the ScalaCompile task:

  1. daemonServer
  2. fork
  3. useAnt
  4. useCompileDaemon

Support for TestNG javadoc annotations has been removed

The support for declaring TestNG tests via javadoc annotations has been removed. The Test.testSrcDirs and the methods on TestNGOptions were removed, too, since they are not needed any more.

Task property annotations on implemented interfaces

In previous versions, annotations on task properties like @InputFile and @OutputDirectory were only taken into account when they were declared on the task class itself, or one of its super-classes. Since Gradle 3.0 annotations declared on implemented interfaces are also taken into account.

eclipse-wtp handling of external dependencies changed

For Java projects, the eclipse-wtp plugin no longer adds external dependencies to the WTP component file, but to the classpath instead. Any customizations related to external dependencies that were made in the eclipse.wtp.component.file hooks now need to be done in the eclipse.classpath.file hooks instead.

eclipse-wtp is automatically applied when the war or ear plugins are applied

User who are building war projects with Eclipse, but for any reason do not want to have WTP enabled can deactivate WTP like this:

eclipse.project { natures.removeAll { it.startsWith('org.eclipse.wst') } buildCommands.removeAll {'org.eclipse.wst') } }

Changes to previously deprecated APIs

Types no longer extend GroovyObject

Eclipse model contains classpath attributes for project and external dependencies

The EclipseProjectDependency and EclipseExternalDependency models now contain ClasspathAttributes. By default the JavaDoc location attribute and WTP deployment attributes are populated.

Any customizations done via eclipse.classpath.file.beforeMerged and eclipse.classpath.file.whenMerged are also reflected in these tooling models.

External contributions

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

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

Known issues

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

GRADLE-3491 - Android Library projects do not pick up changes