Please have a read of the Gradle 1.0-milestone-7 Migration Guide before you use this release. There are some known issues which will be fixed in the next release.
It is now possible to resolve dependency version conflicts by forcing certain versions of transitive dependencies.
So far, forcing versions in Gradle required the user to add extra first level dependency and then configure it to be forced. This might be undesired because it adds extra dependency that may not necessarily be needed. In this release, you can specify forced versions without incurring extra first level dependency. This style of forcing dependency versions will work for both direct and transitive dependencies. We are really keen on improving the dependency management and conflict resolution. In future we plan to support completely customized strategies to resolve version conflicts.
You can read more about the subject in the User Guide section on version conflicts. See examples in the DSL reference for ResolutionStrategy
Gradle will now cache the fact that a module or artifact was not found in a particular repository. This cuts the number of HTTP requests required to resolve modules and artifacts, and moves us closer to being able to provide full offline support. In particular, the IDE tasks can run much faster now that they don't need to re-check for missing source and javadoc artifacts every time.
One side effect of this setup is that if you try to resolve a module but have your repository mis-configured, fixing the repository layout will not immediately make the module available. Gradle uses the cache timeout for changing modules to determine when to recheck a module/artifact that was previously missing. If you require Gradle to rescan all missing modules and artifacts, use:
configurations.all {
resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
}
In a future release we are planning to offer support for dependency resolution in both "offline" module (trust the cache for everything and don't make any remote requests) and "force" mode (verify everything cached to ensure it is up to date).
Gradle now uses a much more efficient locking scheme for accessing the cached dependency information. This means that dependency resolution is faster, in particular, when all the dependencies are cached. This in turn has a big impact on task up-to-date checking, as often a major part of the time taken to figure out whether a task is up-to-date or not, is the time taken to figure out which dependency artifacts to include as the task's inputs.
We have also improved the dependency resolution algorithm, so that it is much faster and uses much less memory for large dependency graphs.
Before attempting to download an artifact from a remote repository, Gradle will now check to see a matching artifact is available for reuse. Various locations will be searched for candidate artifacts, including the current Gradle version, the local Maven repository, and the caches of certain earlier Gradle versions. To check if a candidate artifact matches the remote artifact, Gradle compares the computed SHA1 hash of the local artifact with the value defined in an .sha1 file on the server. If no .sha1 file is available, Gradle will always download the remote artifact.
There are 2 scenarios where local artifact reuse is helpful:
1) When the artifact is not available in the current Gradle cache, but it has been previously downloaded by Maven or an older version of Gradle.
2) When the artifact was previously downloaded from a different repository by the current version of Gradle.
We do expect the Gradle cache layout to be relatively stable over time. However, when the need arises to update the Gradle cache layout, the ability to migrate the cached artifacts in this way should be useful. This feature will also reduce the number of downloads for users switching from Maven to Gradle.
After 1.0-milestone-3, we started using Apache Commons HTTPClient for downloading dependencies, instead of java.net.URL. This allowed us to do pre-emptive authentication among other things. However, in doing so we lost support for standard Java System Properties used for configuring HTTP Proxies.
As of this release, the Java System Properties http.proxyHost, http.proxyPort and http.nonProxyHosts are fully supported by Gradle when performing dependency resolution. See the User Guide section on accessing the web via a proxy for more details.
Previously, Gradle would silently ignore the case where an artifact was declared by a module version, or in a dependency, but could not be downloaded from any of the configured locations. This has now changed, and Gradle will thrown an exception when an attempt is made to retrieve the file for a missing artifact. This will commonly happen when calling configuration.xxx.files, which will attempt to retrieve the file for each declared artifact.
This change should make it easier to ensure that all of the required dependency artifacts have in fact been resolved. For example, previously it was possible for a war file to be published without the necessary jar dependencies, simply if a declared dependency artifact was incorrectly named. In this case Gradle will now throw an exception, rather than silently ignoring the missing artifact.
If a module is published with an incomplete set of artifact files (ie it delcares artifacts that are not present), a dependency on this module will no longer function as normal. We felt that it was better to let users know about potential problems with their dependencies, rather than silently handling broken modules. If it is necessary to resolve the available files for a broken module, you can do so using LenientConfiguration. For example, instead of configurations.compile.files, you would use configuration.compile.resolvedConfiguration.lenientConfiguration.files. Note that the entire DSL syntax for Configuration.files is not supported for LenientConfiguration.files.
Previously, when a transitive dependency was excluded on some dependency effectively it was excluded from the entire configuration. Currently, if you want to exclude a particular transitive dependency from the entire configuration (and in majority of cases this is exactly what you want to do) you should explicitly declare that exclusion on configuration, for example:
configuration.compile.exclude group: "org.unwanted", module: "unwanted"
This change might be a breaking change for certain builds. However, the benefit is more accurate and explicit dependency management. Find out more about the dependency exclusions in the dedicated user guide section.
You can now bundle init scripts into a custom Gradle distribution. These init scripts can inject some custom configuration for every build which uses the distribution. One use of this is to inject some custom plugins into the build script classpath of every project in the build. This configuration can point to plugins in a repository, or plugins bundled into the distribution, or located pretty much anywhere. See the section in the user guide on init scripts.
This release includes some improvements to the init script DSL, to make it easier to configure the projects of a build from your init script. See the section in the user guide on init scripts and the reference for the Gradle class.
Gradle now looks for init scripts in $USER_HOME/.gradle/init.d/ in addition to looking for $USER_HOME/.gradle/init.gradle. See the section in the user guide on init scripts.
In Gradle 1.0-milestone-5, we introduced some locking to make the task up-to-date state multi-process safe. However, this initial locking was coarse-grained, such that you could not run a given build concurrently. For example, this meant that you could not run gradle jettyStop while gradle jettyRun was running. We have now improved the locking scheme, so that it is more efficient and holds the locks for shorter periods. This means that you can, for example, now run gradle jettyStop while gradle jettyRun is running.
We fixed GRADLE-947 so the tarTree() method supports gzip/bzip2 now. tarTree() infers the compression method from the file extension. You can change this default behaviour, if you need to. See an example in the DSL reference.
We also started introducing a Resource concept. What does it mean for a TAR tree? In case your TAR is compressed in some unconventional way, you can still use it with the tarTree() method, so long you provide an implementation of ReadableResource. We want to evolve the concept of resources and use them more and more for better flexibility.
plus all above
Have a look at Gradle 1.0-milestone-7 Release Notes for more information about the new features in this release
Although it is not a supported mechanism, some builds make use of the Task.execute() method to execute a task from some other task. This is broken in Gradle 1.0-milestone-7, so that calling execute() throws an IllegalStateException.
When artifacts for a maven snapshot module (or any changing module) are updated, Gradle 1.0-milestone-7 fails to detect and download the updated artifacts. This occurs regardless of the setting for
cacheChangingModulesFor. As a workaround, you can update the POM file for the snapshot so that Gradle detects that the module has changed: it will then download the snapshot artifacts.
See http://forums.gradle.org/gradle/topics/failure_to_detect_changing_snapshot_dependencies_in_m7_works_in_m6 for more discussion.
Using mavenLocal() as a repository results in a lot of HTTP requests for \*-javadoc.jar and \*-sources.jar. This occurs during pom parsing, and is not helped by caching.
This issue can be mitigated:
Don't use mavenLocal() if your only goal is to reduce remote downloads. In M7, Gradle will reuse artifacts from an .m2 repository even without mavenLocal() declared.
Named parameter buildBy has been deprecated and replaced with builtBy.
previous versions | 1.0-milestone-7 |
---|---|
|
|
See the release notes for more details.
If your intention is to exclude a transitive dependency for the entire configuration please do:
configuration.compile.exclude group: "org.unwanted", module: "unwanted"
For motivations and details please see the release notes.
Previously the Groovy compiler's US-ASCII default was used. Since UTF-8 is compatible with US-ASCII, we don't expect any problems.