Gradle 1.0-milestone-4 includes some nasty performance regressions. You should use either 1.0-milestone-3 or 1.0-milestone-5 instead.
The application plugin now provides direct support for including both static files and extra files generated by your build (e.g. documentation) in the distribution.
Thanks to the contribution from David Gileadi Gradle now offers a new plugin that deals with creating ear archives in a similar fashion as the war plugin handles the war archives. For more information please refer to the ear plugin chapter in the user guide.
A new plugin has been added for creating digital signature for files/artifacts as part of the build. With this initial release, the plugin provides support for generating PGP format signatures (which is the signature format required for publication to the Maven Central repository) but will expand to support other signature formats over time.
See the new userguide chapter on the Signing plugin for more information.
Method repositories.ivy.artifactPattern() now accepts a relative or absolute file name at the start of the pattern. Some examples:
repositories {
ivy {
artifactPattern "${rootDir}/repo/[some-ivy-pattern]"
artifactPattern "../repo/[some-ivy-pattern]"
}
}
Gradle now uses Wharf under the covers as part of its Ivy integration. Wharf includes Ivy cache and repository implementations, which are much improved over the default Ivy implementations, and which fix many long standing bugs and performance problems. Thanks to Wharf, the infamous 'unknown resolver' error message is now a thing of the past. The Wharf cache has a number of nice features, including storing artifacts by their hash, which allows it do deal well with duplicate artifacts, and caching meta-data on a per-resolver basis, which greatly improves the correctness of the results.
Many thanks to our friends at JFrog for providing Wharf and helping us with the integration work.
One implication of changing the artifact cache implementation is that the artifact cache format has changed. This means that Gradle will download your artifacts into their new locations when you run a build using the new version.
Changes to the eclipse/idea plugin were necessary to accommodate the implementation of the Tooling API. Tooling API is necessary for very promising tools like the Eclipse STS gradle plugin. Many properties and methods of idea/eclipse tasks are now deprecated and moved to the relevant idea/eclipse model objects. See examples in dsl guide for IdeaProject, EclipseProject or user guide on idea or eclipse plugin.
Gradle 1.0-milestone-4 Breaking Changes