Gradle Release Notes

Version 1.0-milestone-7

  1. New and Noteworthy
    1. Dependency management improvements.
      1. Version conflict resolution improvements.
      2. Caching the absence of modules and artifacts.
      3. Faster dependency resolution
      4. Better reuse of previously downloaded artifacts
      5. Http Proxy support
      6. Stricter artifact resolution
      7. More accurate transitive dependency exclusions
    2. Improved plugin publication for the enterprise
    3. Init script improvements
    4. Run the same build concurrently
    5. TarTree and Resources
  2. Fixed Jira Issues

Please have a read of the Gradle 1.0-milestone-7 Migration Guide before you use this release. There are some known issues which will be fixed in the next release.

New and Noteworthy

Dependency management improvements.

Version conflict resolution improvements.

It is now possible to resolve dependency version conflicts by forcing certain versions of transitive dependencies.

So far, forcing versions in Gradle required the user to add extra first level dependency and then configure it to be forced. This might be undesired because it adds extra dependency that may not necessarily be needed. In this release, you can specify forced versions without incurring extra first level dependency. This style of forcing dependency versions will work for both direct and transitive dependencies. We are really keen on improving the dependency management and conflict resolution. In future we plan to support completely customized strategies to resolve version conflicts.

You can read more about the subject in the User Guide section on version conflicts. See examples in the DSL reference for ResolutionStrategy

Caching the absence of modules and artifacts.

Gradle will now cache the fact that a module or artifact was not found in a particular repository. This cuts the number of HTTP requests required to resolve modules and artifacts, and moves us closer to being able to provide full offline support. In particular, the IDE tasks can run much faster now that they don't need to re-check for missing source and javadoc artifacts every time.

One side effect of this setup is that if you try to resolve a module but have your repository mis-configured, fixing the repository layout will not immediately make the module available. Gradle uses the cache timeout for changing modules to determine when to recheck a module/artifact that was previously missing. If you require Gradle to rescan all missing modules and artifacts, use:

configurations.all {
    resolutionStrategy.cacheChangingModulesFor 0, 'seconds'

In a future release we are planning to offer support for dependency resolution in both "offline" module (trust the cache for everything and don't make any remote requests) and "force" mode (verify everything cached to ensure it is up to date).

Faster dependency resolution

Gradle now uses a much more efficient locking scheme for accessing the cached dependency information. This means that dependency resolution is faster, in particular, when all the dependencies are cached. This in turn has a big impact on task up-to-date checking, as often a major part of the time taken to figure out whether a task is up-to-date or not, is the time taken to figure out which dependency artifacts to include as the task's inputs.

We have also improved the dependency resolution algorithm, so that it is much faster and uses much less memory for large dependency graphs.

Better reuse of previously downloaded artifacts

Before attempting to download an artifact from a remote repository, Gradle will now check to see a matching artifact is available for reuse. Various locations will be searched for candidate artifacts, including the current Gradle version, the local Maven repository, and the caches of certain earlier Gradle versions. To check if a candidate artifact matches the remote artifact, Gradle compares the computed SHA1 hash of the local artifact with the value defined in an .sha1 file on the server. If no .sha1 file is available, Gradle will always download the remote artifact.

There are 2 scenarios where local artifact reuse is helpful:
1) When the artifact is not available in the current Gradle cache, but it has been previously downloaded by Maven or an older version of Gradle.
2) When the artifact was previously downloaded from a different repository by the current version of Gradle.

We do expect the Gradle cache layout to be relatively stable over time. However, when the need arises to update the Gradle cache layout, the ability to migrate the cached artifacts in this way should be useful. This feature will also reduce the number of downloads for users switching from Maven to Gradle.

Http Proxy support

After 1.0-milestone-3, we started using Apache Commons HTTPClient for downloading dependencies, instead of This allowed us to do pre-emptive authentication among other things. However, in doing so we lost support for standard Java System Properties used for configuring HTTP Proxies.

As of this release, the Java System Properties http.proxyHost, http.proxyPort and http.nonProxyHosts are fully supported by Gradle when performing dependency resolution. See the User Guide section on accessing the web via a proxy for more details.

Stricter artifact resolution

Previously, Gradle would silently ignore the case where an artifact was declared by a module version, or in a dependency, but could not be downloaded from any of the configured locations. This has now changed, and Gradle will thrown an exception when an attempt is made to retrieve the file for a missing artifact. This will commonly happen when calling, which will attempt to retrieve the file for each declared artifact.

This change should make it easier to ensure that all of the required dependency artifacts have in fact been resolved. For example, previously it was possible for a war file to be published without the necessary jar dependencies, simply if a declared dependency artifact was incorrectly named. In this case Gradle will now throw an exception, rather than silently ignoring the missing artifact.

If a module is published with an incomplete set of artifact files (ie it delcares artifacts that are not present), a dependency on this module will no longer function as normal. We felt that it was better to let users know about potential problems with their dependencies, rather than silently handling broken modules. If it is necessary to resolve the available files for a broken module, you can do so using LenientConfiguration. For example, instead of configurations.compile.files, you would use configuration.compile.resolvedConfiguration.lenientConfiguration.files. Note that the entire DSL syntax for Configuration.files is not supported for LenientConfiguration.files.

More accurate transitive dependency exclusions

Previously, when a transitive dependency was excluded on some dependency effectively it was excluded from the entire configuration. Currently, if you want to exclude a particular transitive dependency from the entire configuration (and in majority of cases this is exactly what you want to do) you should explicitly declare that exclusion on configuration, for example:

configuration.compile.exclude group: "org.unwanted", module: "unwanted"

This change might be a breaking change for certain builds. However, the benefit is more accurate and explicit dependency management. Find out more about the dependency exclusions in the dedicated user guide section.

Improved plugin publication for the enterprise

You can now bundle init scripts into a custom Gradle distribution. These init scripts can inject some custom configuration for every build which uses the distribution. One use of this is to inject some custom plugins into the build script classpath of every project in the build. This configuration can point to plugins in a repository, or plugins bundled into the distribution, or located pretty much anywhere. See the section in the user guide on init scripts.

Init script improvements

This release includes some improvements to the init script DSL, to make it easier to configure the projects of a build from your init script. See the section in the user guide on init scripts and the reference for the Gradle class.

Gradle now looks for init scripts in $USER_HOME/.gradle/init.d/ in addition to looking for $USER_HOME/.gradle/init.gradle. See the section in the user guide on init scripts.

Run the same build concurrently

In Gradle 1.0-milestone-5, we introduced some locking to make the task up-to-date state multi-process safe. However, this initial locking was coarse-grained, such that you could not run a given build concurrently. For example, this meant that you could not run gradle jettyStop while gradle jettyRun was running. We have now improved the locking scheme, so that it is more efficient and holds the locks for shorter periods. This means that you can, for example, now run gradle jettyStop while gradle jettyRun is running.

TarTree and Resources

We fixed GRADLE-947 so the tarTree() method supports gzip/bzip2 now. tarTree() infers the compression method from the file extension. You can change this default behaviour, if you need to. See an example in the DSL reference.

We also started introducing a Resource concept. What does it mean for a TAR tree? In case your TAR is compressed in some unconventional way, you can still use it with the tarTree() method, so long you provide an implementation of ReadableResource. We want to evolve the concept of resources and use them more and more for better flexibility.

plus all above

Fixed Jira Issues

Jirra Issues
Type Key Summary Assignee Reporter Priority Status Resolved Created Uploaded Due
GRADLE-2020 Locked cache directory Adam Murdoch Benjamin Muschko Resolved Fixed 31/Dec/11 04/Jan/13
GRADLE-2003 With transition to httpclient library the proxy settings are not picked up anymore Unassigned Dmitry Kozlov Resolved Fixed 17/Dec/11 04/Jan/13
GRADLE-2002 Getting Sonar to reuse Cobertura reports in a multi-project analysis Peter Niederwieser Gradle Forums Resolved Fixed 14/Dec/11 04/Jan/13
GRADLE-1999 Jars from additional maven repo not added to build classpath Unassigned Kurt Harriger Resolved Fixed 12/Dec/11 04/Jan/13
GRADLE-1994 Duplicate build path entry (src/main/java) Unassigned Cengiz Öztürk Resolved Fixed 10/Dec/11 04/Jan/13
GRADLE-1987 gradle --stop does not stop daemons that are running with a different java home Adam Murdoch Adam Murdoch Resolved Fixed 07/Dec/11 04/Jan/13
GRADLE-1986 Milestone-6 dependency resolution keeps on going Adam Murdoch Gradle Forums Resolved Fixed 07/Dec/11 04/Jan/13
GRADLE-1985 Changing modules don't get retrieved when the changing property is once switched off. Daz DeBoer Hans Dockter Resolved Fixed 06/Dec/11 04/Jan/13
GRADLE-1984 Running gradle eclipse twice results in duplicated java source entries in .classpath Unassigned Sergey Kadaner Resolved Fixed 06/Dec/11 04/Jan/13
GRADLE-1977 Links from DSL reference to API documentation don't work anymore Unassigned Peter Niederwieser Resolved Fixed 01/Dec/11 04/Jan/13
GRADLE-1976 (M5 / M6) Cannot lock the artifact cache, as it is already locked by this process Unassigned Gradle Forums Resolved Fixed 01/Dec/11 04/Jan/13
GRADLE-1975 Default artifact is not resolved for maven dependencies that are declared with packaging = 'pom' Daz DeBoer Daz DeBoer Resolved Fixed 30/Nov/11 04/Jan/13
GRADLE-1973 Gradle does not report missing/failed artifact downloads Unassigned Gradle Forums Resolved Fixed 30/Nov/11 04/Jan/13
GRADLE-1972 ChangingPattern of a custom DependencyResolver is ignored Daz DeBoer Daz DeBoer Resolved Fixed 29/Nov/11 04/Jan/13
GRADLE-1971 1.0-milestone-6 cannot contact Maven Central when using a proxy Unassigned Gradle Forums Resolved Fixed 29/Nov/11 04/Jan/13
GRADLE-1968 Dependency resolution became awfully slow with milestone 6 Adam Murdoch Bernhard Messerer Resolved Fixed 28/Nov/11 04/Jan/13
GRADLE-1962 Gradle 1.0-milestone-6 cannot access to repositories via proxy Unassigned Yasuharu NAKANO Resolved Fixed 25/Nov/11 04/Jan/13
GRADLE-1954 Javadoc DSL for IvyArtifactRepository has wrong method name for ivy artifact pattern Unassigned Frederic Simon Resolved Fixed 23/Nov/11 04/Jan/13
GRADLE-1953 "gradle eclipse" creates duplicate classpath entries in 1.0-milestone-6 Daz DeBoer Ben McCann Resolved Fixed 22/Nov/11 04/Jan/13
GRADLE-1948 If a test marks the current thread as interrupted, test execution will never complete Luke Daley Luke Daley Resolved Fixed 21/Nov/11 04/Jan/13
GRADLE-1943 Base plugin required for building and publishing artifacts, while documentation suggest otherwise Szczepan Faber nitko nigdje Resolved Fixed 18/Nov/11 04/Jan/13
GRADLE-1933 tooling api is not thread safe even if no instances are shared Szczepan Faber Szczepan Faber Resolved Fixed 16/Nov/11 04/Jan/13
GRADLE-1905 Test reports should only show actual exception but not PlaceholderException Peter Niederwieser Peter Niederwieser Resolved Fixed 08/Nov/11 04/Jan/13
GRADLE-1885 Jar task should not create build/tmp/x directory when it's not executed Luke Daley Matias Bjarland Resolved Fixed 02/Nov/11 04/Jan/13
GRADLE-1860 TestNG 6.3 is not supported Peter Niederwieser Nikolay Rybak Resolved Fixed 22/Oct/11 04/Jan/13
GRADLE-1822 testng configuration failures resulting in skipped tests do not fail the build Peter Niederwieser Doug Lethin Resolved Fixed 08/Oct/11 17/Jun/14
GRADLE-1801 Could not open cache directory ... taskArtifacts Unassigned Basile Chandesris Resolved Fixed 20/Sep/11 04/Jan/13
GRADLE-1797 tooling api should not reset java logging when embedded Szczepan Faber Szczepan Faber Resolved Fixed 15/Sep/11 04/Jan/13
GRADLE-1776 Gradle should degrade gracefully if jna integration is not available for the current platform Unassigned Adam Murdoch Resolved Fixed 31/Aug/11 04/Jan/13
GRADLE-1765 Gradle Tooling API not obeying Gradle Wrapper settings for subprojects Unassigned Kris De Volder Resolved Fixed 25/Aug/11 04/Jan/13
GRADLE-1724 Dependency resolution against SSL repo hang and make m4 unusable Daz DeBoer Hani Suleiman Resolved Fixed 05/Aug/11 04/Jan/13
GRADLE-1063 Optionally omit Ivy logging output when running gradle with -i option Unassigned Chris Beams Resolved Fixed 28/Jul/10 04/Jan/13
GRADLE-1056 eclipse plugin duplicates src/main/java entry in .classpath Unassigned Philip Crotwell Resolved Fixed 27/Jul/10 04/Jan/13
GRADLE-947 Add gzip support to TarFileTree Unassigned Brian Sanders Resolved Fixed 26/May/10 04/Jan/13
GRADLE-861 Please improve the error message when trying to use "null" as a dependency notation Unassigned Reinhard Mantey Resolved Fixed 23/Mar/10 04/Jan/13
GRADLE-699 Make it easier to set project properties from the init script Unassigned Adam Murdoch Resolved Fixed 14/Oct/09 04/Jan/13
GRADLE-607 Add dynamic property support to Gradle class Unassigned Adam Murdoch Resolved Fixed 28/Aug/09 04/Jan/13
GRADLE-25 Add JDepends Coverage reports Unassigned Hans Dockter Resolved Fixed 09/Apr/08 04/Jan/13

1.0-milestone-7 Migration Guide

Have a look at Gradle 1.0-milestone-7 Release Notes for more information about the new features in this release

  1. Known Issues
    1. Cannot call {{Task.execute()}} from task actions
    2. Maven snapshot artifacts not updated
    3. Using mavenLocal() causes spurious HTTP requests
  2. Notable deprecations
    1. Source sets
  3. Breaking Changes
    1. Stricter artifact resolution
    2. Per-dependency exclude rules no longer may span to the entire configuration.
    3. Source encoding for GroovyCompile task now defaults to UTF-8

Known Issues

Cannot call Task.execute() from task actions

Although it is not a supported mechanism, some builds make use of the Task.execute() method to execute a task from some other task. This is broken in Gradle 1.0-milestone-7, so that calling execute() throws an IllegalStateException.

Maven snapshot artifacts not updated

When artifacts for a maven snapshot module (or any changing module) are updated, Gradle 1.0-milestone-7 fails to detect and download the updated artifacts. This occurs regardless of the setting for
cacheChangingModulesFor. As a workaround, you can update the POM file for the snapshot so that Gradle detects that the module has changed: it will then download the snapshot artifacts.

See for more discussion.

Using mavenLocal() causes spurious HTTP requests

Using mavenLocal() as a repository results in a lot of HTTP requests for \*-javadoc.jar and \*-sources.jar. This occurs during pom parsing, and is not helped by caching.

This issue can be mitigated:

Don't use mavenLocal() if your only goal is to reduce remote downloads. In M7, Gradle will reuse artifacts from an .m2 repository even without mavenLocal() declared.


Notable deprecations

Source sets

Named parameter buildBy has been deprecated and replaced with builtBy.

previous versions 1.0-milestone-7

sourceSets.main.output.dir("generated", buildBy: "generatorTask"                    


sourceSets.main.output.dir("generated", builtBy: "generatorTask"                    

Breaking Changes

Stricter artifact resolution

See the release notes for more details.

Per-dependency exclude rules no longer may span to the entire configuration.

If your intention is to exclude a transitive dependency for the entire configuration please do:

configuration.compile.exclude group: "org.unwanted", module: "unwanted"

For motivations and details please see the release notes.

Source encoding for GroovyCompile task now defaults to UTF-8

Previously the Groovy compiler's US-ASCII default was used. Since UTF-8 is compatible with US-ASCII, we don't expect any problems.