Gradle 1.0-milestone-6 Release Notes

Skip to end of metadata
Go to start of metadata

New and Noteworthy

We are very happy with our speed of progress. We were able to deliver a decent chunk of important improvements and new features over the last couple of weeks. We are getting close to finish everything we consider as required for releasing 1.0.

Faster dependency resolution

Dependency resolution is overall faster in this release, and in some cases, very much faster.

To get into the details, we need to introduce some terminology. Feel free to skip to the next section if 'dependency resolution is faster' is a good enough explanation for you.

  • Dynamic versions are dependencies that are specified via some pattern instead of a fixed version (e.g. "junit:junit:4.+). The actual resolved dependency artifacts never change.
  • Changing modules are dependencies where the actual artifacts may change. Maven snapshots without a timestamp are an example of this. Changing modules are not a very good pattern. But for legacy reasons you often need to deal with those.

For a more detailed description of the changes below you may also have a look at this forum post.

Caching and caching timeouts for resolving dynamic versions

In previous Gradle versions, the default behavior for dealing with dynamic versions was to check for newer versions on every resolve. You could change this behavior by using some custom Ivy specific TTL system properties. We have implemented our own engine for dealing with this. By default cache entries expire in 24 hours. The user guide describes how to change this.

Caching and caching timeouts for resolving changing modules

If a dependency is flagged as changing, or a resolver tells us the module is changing (eg SNAPSHOT), we remember when we last fetched the module meta-data and artifacts. If we find a cache entry indicating it's ok to use the cached version, we use them. Otherwise, we check for changes to the descriptor and artifacts. Changing Module cache entries expire by default in 24 hours. The user guide describes how to change this.

Maven snapshots are always interpreted by Gradle as changing modules, also in the normal case when they have a timestamp. In the cache you will always only find a file foo-SNAPSHOT.jar. This is for Ivy legacy reasons. We will improve this in a future release.

Much faster resolves from Maven repositories

For reading from Maven repositories Gradle always delegated to the default Ivy resolve engine. We have now implemented our own resolve engine. This has dramatically reduced the number of HTTP requests when resolving dependencies from a Maven repository and thus dramatically improved the resolve performance.

What comes next

Performance is very dear to us. This release had a strong focus on avoiding any unnecessary network lookups. For example we had a lot of issues where the cache timeouts for Maven snapshots were not considered when using multiple repositories. This should be all solved now. For the next release we will do some work on improving the performance of cache lookups and do in-memory caching.

Option to log test output to the console

Gradle pays a lot of attention to provide a clean and concise console output, without unnecessary clutter that hides the important things. Therefore Gradle does not show the output of the tests on the console. This is still a very reasonable default behavior. So far the only way to see the test output was to look at the test reports. But there are scenarios where it is very helpful to see the test output directly. For example we have users with very slow running and somehow fragile tests. The test output serves here as a poor men progress bar as well as showing that nothing is stalled. This has been a very popular Jira ticket.

Now there is a simple way to simply switch on all test output on the console. You can also hook in a listener to have full control what test output is shown.

Option to fail dependency resolution on version conflict

By default, gradle uses 'newest' conflict resolution strategy. See the section about version conflicts in the user guide. Now you can also tell gradle to fail eagerly on version conflict. See the example here.

We plan to allow for custom version conflict resolution policies in the future.

Password Protected Maven Repositories

It is now possible to specify a username/password combination to access a maven repository protected with basic authentication. 
Previously, it was necessary to use special ivy properties to do this, and it wasn't possible to configure this on a per-repository basis.

The syntax for specifying credentials for accessing a maven repository is described here.

Publish artifacts other than archives

You can now easily publish any type of file. Previously, you could only publish archive files built by Gradle.

See the user guide for details.

Build announcements plugin

This plugin uses the announce plugin to generate announcements to the local desktop about interesting events in the build lifecycle. Very useful for longer builds, and with the --continue command-line option. See the user guide for details of using it.

This plugin is currently experimental. It may change in future Gradle versions.

Announce plugin improvements

A new local announcer type has been added, which chooses an appropriate type based on the local platform for sending announcements to the local desktop.

The growl announcer no longer requires 'growl-notify' installed when running under the Apple JVM on Mac OS X.

Daemon Improvements

If you are using Gradle with the daemon enabled each build involves two JVM instances. One is the long running daemon JVM that actually executes the build. The other one is a JVM that is fired up for the time of a running build. This is what we call the build client. It triggers the execution of the build in the daemon JVM and is responsible for the console input and output.

The Gradle Daemon now correctly works with builds that accept input (e.g. a build prompting a user for a password). Previously, the Gradle Daemon was not able to access any input provided to the “client” process that initiated the build. This now works correctly and is completely transparent. 

The Gradle Daemon now respects the build clients Java version. This means that if an existing Gradle Daemon is available to service a build request, but is using a different Java version than what the build client is using, a new Gradle Daemon will be started with the desired Jave version.

DSL Tweaks

Project.files() now accepts a Task. Resolves to the output files of the task.

Upgraded to Groovy 1.8.4

Build scripts are now executed using Groovy 1.8.4 (instead of 1.7.10). Because Groovy does not guarantee binary backwards-compatibility between major versions, binary plugins written in Groovy may have to be recompiled to work with this Gradle version. This also holds for third-party plugins.

Migration

Fixed Jira Issues

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.