- New and Noteworthy
- Faster dependency resolution
- Caching and caching timeouts for resolving dynamic versions
- Caching and caching timeouts for resolving changing modules
- Much faster resolves from Maven repositories
- What comes next
- Option to log test output to the console
- Option to fail dependency resolution on version conflict
- Password Protected Maven Repositories
- Publish artifacts other than archives
- Build announcements plugin
- Announce plugin improvements
- Daemon Improvements
- DSL Tweaks
- Upgraded to Groovy 1.8.4
- Fixed Jira Issues
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Project.files() now accepts a Task. Resolves to the output files of the task.
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.
- Migrating from 1.0-milestone-5: Gradle 1.0-milestone-6 Migration Guide
- Migrating from 1.0-milestone-4: Gradle 1.0-milestone-5 Migration Guide plus all above
- Migrating from 1.0-milestone-3: Gradle 1.0-milestone-4 Breaking Changes plus all above