Gradle Release Notes

Version 0.7

  1. New and Noteworthy
  2. Migrating from 0.6
  3. Credits
  4. Fixed Jira Issues

New and Noteworthy

Native Ant build support

Gradle can import Ant build scripts into your project. Gradle integrates deeply with the Ant build. Every Ant target is represented as a Grade task. This task can be further enhanced in your Gradle build script. The integration even works in both ways. You can depend on Gradle tasks in your build.xml. In addition, accessing and modifying Ant properties from your build script is now much easier.

See UG 14 for details.

Declare build script classpath in the build script

You can now declare the classpath to compile and execute a build script in the build script itself. You no longer require a settings.gradle file to specify this classpath. In addition, each build script in a multi-project build can specify its own classpath.

See UG 28.2 for details.

File dependencies

You can now declare dependencies using a collection of Files. This can be a simple alternative to using a repository, or if you want complete control over which files are used for certain dependencies.

See UG 25.3.5 for details.

Retrieving subset of files from a Configuration

The Configuration class now offers a files method to retrieve the files for a subset of the configuration dependencies.

See UG 25.4 for details.

Improved Copy task

The Copy task now provides a rich API for specifying source and destination files, and finer-grained control over file inclusion and exclusion. Also, the Copy task now provides the ability to rename files and filter content as they are copied.

See the Javadoc for the Copy task for more details.

Dry Run

With the -m option you can execute the Gradle build with all task actions disabled. That way you can see what and in which order a particular Gradle build executes.

See UG 9.4 for details.

Embedded Usage

Gradle has improved its API to be easily used in an embedded way. This is not covered in the UG yet. There is just a placeholder chapter: UG 31. Stay tuned for improved documentation on this important issue.

Plugin Listener

Gradle provides now listeners for plugin usage. A build script or other plugins can add such listeners. They get informed about plugins that are already available and as soon as a new plugin comes into use.

Migrating from 0.6

Gradle 0.7 Breaking Changes


Again many thanks to Steve Appling and his team for all their valuable patches and their feedback. Steve contributed for example the new copy functionality and the ground work for build optimization that we plan to fully deliver with Gradle 0.8. Many thanks also to Tomek Kaczanowski for the docbook user's guide patches. Thanks to Dierk König, Donal McNamee, Galder Zamarreño, Haug Bürger, Jerod Lass, Marc Guillemot, Markus Kobler, Mike, Niko Schmuck, Paul Gier, Peter Niederwieser for their Jira's and other feedback.

Fixed Jira Issues

0.7 Breaking Changes

Build Script Changes

Groovy 1.6.3

Build scripts and plugins are now executed using Groovy 1.6.3. While most build scripts should be fine with this change, this does have the potential to break some existing builds.

Java plugin task dependency changes

The Java plugin inter-task dependencies have changed. See UG 16.1.

There is also no init task any longer for the Java plugin. Use:

build.taskGraph.whenReady {
    // do something

to do stuff that should be done before any task gets executed.

Eclipse plugin split out of Java plugin

The eclipse tasks have been split out of the Java plugin and into a new 'eclipse' plugin.

usePlugin 'eclipse'

Unmanaged classpath merged into compilation configurations

The unmanaged classpath from the compile and compileTests tasks have been merged into the compile and testCompile configurations respectively. These are also inherited by the runtime and testRuntime configurations.

compile.unmanagedClasspath(...some files...) dependencies { compile files(..some files..) }

Compile task

* unmanagedClasspath and configuration properties have been merged into the classpath property.

Test task

* unmanagedClasspath property has been merged into the configuration property.

Copy task

The API of the Copy task has changed.

ClassLoader changes

Each project now has its own ClassLoader, with its parent set to the ClassLoader of the parent project. The root ClassLoader also includes the runtime from the buildSrc project, if any. These changes should not be a problem for most builds.

Settings Script Changes

It is no longer possible to specify the build classpath in the settings file. This has been moved into the build script itself.

API Changes


* Project.getBuildFileClassName() has been removed.


* Task.defineProperty() has been renamed to setProperty()


* Configuration.getProjectDescriptors() as been replaced by getDescriptors(Class<T> type) * Configuration.getAllProjectDescriptors() as been replaced by getAllDescriptors(Class<T> type)


The Dependency hierarchy has been reorganised.


The Plugin interface has changed from

public interface Plugin {
    void apply(Project project, PluginRegistry pluginRegistry, Map<String, ?> customValues);


public interface Plugin {
    void use(Project project, ProjectPluginsContainer projectPluginsHandler);

Most plugins just use the project argument and therefore simply to need to change the signature to work again.