Gradle 1.0-milestone-7 snapshot available

A new Gradle 1.0-milestone-7 snapshot is now available. This snapshot contains a large number of improvements and bug fixes for dependency resolution, plus a few other features. Please have a read of the release notes for details, and a list of bug fixes.

Please give this snapshot a try, and let us know you go. In particular, we’re interested in hearing from you if you were experiencing dependency resolution performance problems with earlier versions of Gradle. Download the distribution or point your wrapper at

Before you try out the snapshot, you should have a read of the migration guide, as there are a small number of deprecations and breaking changes.

I just tested on my build and the results were fantastic.

I ran “./gradlew clean cleanEclipse eclipse build --no-daemon”

The first run took over 16 minutes, but subsequent runs were smoking – about 1 minute each, compared to over 2 minutes with milestone 6.

Keep those improvements coming!

Mostly worked okay on my build. (currently milestone-3)

3 issues encountered though:

  1. Got a concurrentmodificationexception when running: gradle tasks 2) ‘’ resolved to ‘’, so I had to change to ‘’ 3) ‘’ which has a dependency to jsr181 failed to resolve the latter. Had to exclude it from jaxws-api and then explicitly add a dependency to jsr181 with @pom

One of my problems with unresolved dependencies ( is now fixed :slight_smile: All my other projects are running fine so far. Good work I would say.

Nice to see the http proxy support is fixed. A bit less nice is that it now breaks when the proxy (typically Squid) uses the gzip encoding for the response…

This is described in GRADLE-2007.

Sorry, forgot to thank you for your great work so far!

Thanks a lot for your efforts!

For me, the snapshot works better than M5 and M6 when coming from M3…

Does this include the fix for GRADLE-947? I just tried it with a tar.bz2 file and it did not work. Is that not an expected file extension?

Unable to expand TAR ‘/localhome/aogail/.gradle/caches/artifacts-7/artifacts/326e543bbd4610b93eb951fa9d9ee4b1/com.tripwire.cap/idl/1.0.0r45.b7/tar.bz2/idl-1.0.0r45.b7.tar.bz2’

The tar might be corrupted or it is compressed in an unexpected way.

By default the tar tree tries to guess the compression based on the file extension.

If you need to specify the compression explicitly please refer to the DSL reference.

Do you have a stacktrace for this error? You can run Gradle with -s to get the stacktrace.

Do you have stack traces for the failures?

I posted it to to avoid cluttering this page.

This should be fixed now. Can you try

Nope, still not working. See below:

:compileJava Download Download [ant:javac] error: error reading /var/lib/jenkins/.gradle/caches/artifacts-7/artifacts/56865c09425cc6ecda8606d7e6035ceb/commons-collections/commons-collections/3.2/jar/commons-collections-3.2.jar; error in opening zip file

When examining:

$ file -L /var/lib/jenkins/.gradle/caches/artifacts-7/artifacts/56865c09425cc6ecda8606d7e6035ceb/commons-collections/commons-collections/3.2/jar/commons-collections-3.2.jar /var/lib/jenkins/.gradle/caches/artifacts-7/artifacts/56865c09425cc6ecda8606d7e6035ceb/commons-collections/commons-collections/3.2/jar/commons-collections-3.2.jar: gzip compressed data, from Unix

Using gunzip on it results in a perfectly normal JAR file.

Hmmm. This means that Squid is returning GZipped content even when the request has “Accept-Encoding: Identity” in the HTTP headers. Can you please run with “–debug” to confirm that these headers are indeed being sent? You’ll need to clear the cache of these entries to force Gradle to attempt to download them again.

@aogail, having looked at the stack trace, I saw this kind of error when the tar was incorrect (for example the tar was just a text file or a folder, etc.). I think the uncompressing worked fine and was passing a readable inputstream to the untarring logic. Can you somehow verify that the compressed tar is all good?

Yes, this same tar file works with a local version of gradle, to which I added tgz/tbz2 support. (It’s the same code from )

Hmmm, that’s weird. Could you send me this tar, please (szczepiq at gmail)? (or create a jira ticket and attach the tar). That would be very helpful to investigate it :slight_smile:

I created

Yep, I can confirm the Accept-Encoding: identity header is sent in 1.0M7. It seems our Squid installation is configured to replace it with gzip. I understand this tends to be quite common since practically all clients support gzip, and this makes browsers such as IE6 more efficient. It might also be Squid’s default configuration.

Our problem was solved in another way, however as this might be a surprisingly common situation I’d suggest thinking about supporting the more common compression formats. I understand support is readily available for HttpClient 4 as a contrib package.

Yep we’re in the process of upgrading to HttpClient4, which will give us out-of-the-box support for GZip encoding as well as other goodness. Glad you worked it out, and thanks for the report.