Gradle Release Notes
Version 1.0-milestone-5
New and Noteworthy in 1.0-milestone-5
Experimental C+\+ support
Some basic support for building binaries and libraries from C++ source is now included in Gradle. Currently only supports gcc. See C++ Support.
Improved Sonar plugin
The Gradle Sonar plugin has been redesigned and rewritten from scratch. It can now analyze a whole project hierarchy at once. This yields a hierarchical view in the Sonar web interface, with aggregated metrics and the ability to drill down into subprojects. Analyzing a project hierarchy at once is also much faster and less likely to run into out-of-memory problems than analyzing each project separately.
The plugin is now configured via proper and well documented configuration objects and offers many sensible defaults. Hooks exist to set custom Sonar properties. The Sonar chapter in the user guide has been revised and enhanced. See Sonar Plugin.
Caches handle concurrent access from multiple processes
All caches maintained by Gradle are now multi-process safe, and much more robust in the face of failures.
This means that you can safely run multiple builds on the same machine. For example, now you can remove any workarounds for your build servers which gave each CI build a separate home directory.
This change means that Gradle will do a much better job of recovering when you kill the build with a ctrl-c or the kill command.
\--continue command line option
When you run Gradle with this command line option, it will continue execution when execution for a task fails, while still honoring task dependencies. Using this option you will get the maximum feedback from a build.
Improved signing plugin
Signatures are now automatically added to the 'archives' configuration, so there is no longer any need for a separate configuration in order to publish to a maven or ivy repository. You can simply use gradle uploadArchives as normal.
Improved profile report
The profile report now includes information about dependency resolution times.
New DSL extension mechanism for plugins
A new mechanism for plugins to use to extend the DSL has been added. See Writing Custom Plugins.
Repository DSL changes
A repositories.maven {} method has been added. The repositories.ivy() method has been improved, so that you can now provide separate patterns for the artifacts and ivy descriptor, or use one of the new built-in layouts. See Repositories.
New dependency management tutorial
A tutorial chapter has been added to the user guide, introducing the basics of dependency management in Gradle. See Dependency Management Basics.
New and Noteworthy in 1.0-milestone-4
Application plugin enhancements
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.
New plugin: "ear"
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.
New plugin: "signing"
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.
Easier Ivy repositories
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]"
}
}
New artifact cache implementation
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.
and Gradle 1.0-milestone-4 Breaking Changes
Fixed Jira Issues
Resolved
1.0-milestone-5 Migration Guide
Have a look at Gradle 1.0-milestone-5 Release Notes for more information about the new features in this release
Known Issues
There are some known issues in this release. They will be fixed in the next release of Gradle:
- Poor performance when using snapshot dependencies and dynamic revisions with multiple repository declarations. This does not affect you if you are using a repository manager and use aggregate/virtual repositories for multiple physical repositories.
- Timeout failures when running the same build concurrently. See GRADLE-1801. There is currently no work around.
- Some artifacts go missing from project dependencies when using classifiers. This only affects you in the rare situation, that the artifacts with classifiers are supposed to be in the classpath of the project. This is for example not the case for your source or javadoc jars. See GRADLE-1838, where you can also find a work around.
- Artifactory and signing plugins do not work together. See GRADLE-1845. There is currently no work around.
Breaking Changes
Artifact publication
The default configuration no longer extends the archives configuration. This means that if you want to make artifacts other than the default Jar available in the compile and runtime classpaths in other projects, you will need to add your additional artifacts to the runtime configuration:
| 1.0-milestone-4 | 1.0-milestone-5 |
|---|---|
|
|
Assemble and Build tasks
The assemble and build tasks now builds only those artifacts added to the archives configuration, rather than all the archive tasks in the project. The assemble task also builds artifacts added indirectly to the archives configuration, such as those added to the runtime configuration. If you need a task that assembles all archives regardless of whether they are published or not, you can create one like this:task assembleAll(dependsOn: tasks.withType(AbstractArchiveTask))
To change the assemble task back to its old behaviour, you can do:
assemble {
dependsOn = tasks.withType(AbstractArchiveTask)
}
Build script classpath
Jars added to the Gradle distribution (that is, jars that have been manually added and are not part of the standard Gradle distribution) in $gradleHome/lib and $gradleHome/lib/plugins are no longer visible in the build script classpaths. If you wish to make some library available in the build script classpath, you can do this:
buildscript {
repositories { ... add some repositories ... }
dependencies {
classpath 'group:module:version'
}
}
Source sets
When a source set is added, the corresponding compile and runtime configurations are also added. Generally, this should not be a problem.Sonar Plugin
- The Sonar plugin now requires Sonar 2.9 or higher.
- The task added by the Sonar plugin was renamed from sonar to sonarAnalyze.
- The DSL for the Sonar plugin was completely redesigned. For more information, see the Sonar chapter in the user guide.
Convention DSL
Convention implementations no longer expose the convention properties and methods on themselves. For example:
apply plugin: 'java'
// no longer works
project.convention.sourceCompatibility = 1.6
// still works
project.sourceCompatibility = 1.6
sourceCompatibility = 1.6
Repository APIs
The APIs that provide the repository DSL have changed. These changes should generally be backwards compatible from the DSL.- RepositoryHandler now extends ArtifactRepositoryContainer and contains a list of Gradle ArtifactRepository instances instead of Ivy DependencyResolver instances. This change does not affect how you define your repositories, but may affect any code which iterates over or otherwise queries the contents of the project.repositories or upload.repositories containters.
- RepositoryHandler no longer extends ResolverProvider. The getResolvers() method is still available.
- Methods mavenInstaller() and mavenDeployer() are now only available when the maven plugin is applied.
- MavenResolver now extends ArtifactRepository instead of Ivy DependencyResolver. Again, this change does not affect how you define your repositories.
- RepositoryHandler.flatDir() now returns a FlatDirectoryArtifactRepository rather than an Ivy DependencyResolver.
Project methods
The TaskContainer.getByName() method was unintentionally available via Project in previous releases. You should instead use one of the supported methods for accessing a task:1.0-milestone-4
project.getByName("someTask")
1.0-milestone-5
project.tasks.getByName("someTask")
// or
project.task.someTask
// orproject.someTask
Deprecated API methods
- Configuration.addDependency() has been deprecated. Use Configuration.getDependencies().add() instead.
- Configuration.addArtifact() has been deprecated. Use Configuration.getArtifacts().add() instead.
- Configuration.removeArtifact() has been deprecated. Use Configuration.getArtifacts().remove() instead.
- Configuration.getDependencies(type) has been deprecated. Use Configuration.getDependencies().withType(type) instead.
- Configuration.getAllDependencies(type) has been deprecated. Use Configuration.getAllDependencies().withType(type) instead.
- Configuration.getBuildArtifacts() has been deprecated. Use Configuration.getAllArtifacts().getBuildDependencies() instead.
- Configuration.getAllArtifactFiles() has been deprecated. Use Configuration.getAllArtifacts().getFiles() instead.
- ResolverHandler.addLast(Object) has been deprecated. Use add(ArtifactRepository) or maven(Closure) instead.
- ResolverHandler.addLast(Object, Closure) has been deprecated. Use add(ArtifactRepository) or maven(Closure) instead.