New and Noteworthy
Tooling API improvements
Tooling API allows providing build arguments for running tasks or building model.
When running builds via the Tooling API you can now specify build arguments such as --no-search-upward, --project-dir, --info, --debug, etc. This significantly improves the usability of the Tooling API to drive builds. You can expect this feature to be quickly picked up by the STS Eclipse Gradle plugin and Intellij IDEA plugin.
This feature also means that you can write automated tests for your custom Gradle plugins in a more convenient way than before. Specifically, you can use the Tooling API to drive test builds that use your plugins. Previously, in order to integ-test your custom Gradle plugins you had to either call GradleMain directly or use deprecated GradleLauncher API. Neither of those options was convenient because of the hassle with setting up the classpath right. We will provide more information about new ways for writing integration tests for your Gradle plugins soon.
Passing build arguments might also be useful if you use the Tooling API for getting the model. For example, it is now possible to acquire a model for a project that uses custom build file (i.e. not 'build.gradle') because you can specify the --build-file argument.
For more information about the feature please refer to docs for LongRunningOperation.withArguments(). Code sample is included in the docs for BuildLauncher or ModelBuilder.
New Groovy compiler integration
Improved artifact change detection
The strategy for detecting whether a remote HTTP resource (e.g. jar dependency) has actually changed and needs to be downloaded has been improved to support more servers/repositories. This impacts dependency resolution where a dependency is considered to be “changing”. Gradle allows you toconfigure a TTL for changing dependencies. When that TTL expires, Gradle will check to see if the resource has changed and needs to be downloaded again.
Gradle will now first compare ETag header values, if the ETag has changed since last time the resource was downloaded it is considered to be changed. If the server does not send ETags, Gradle will fallback to comparing the Last Modified and Content Length values. If either of these values have changed since the last time Gradle downloaded the resource at that URL, the resource is considered changed and will be downloaded. If the server does not offer Last Modified and Content Length headers, Gradle will then check for a sha1 checksum published alongside the resource and compare it with the checksum of the cached file.
FileSystemResolver no longer subject to caching
When using Ivy's FileSystemResolver artifacts will not be subject to caching by Gradle. The files will be used where they exist on the file system (therefore any changes are picked up immediately). In previous versions of Gradle, the artifacts were copied into the local cache and subject to the same “changing” checking as remote artifacts.
New command-line options
- --recompile-scripts forces build script recompiling.
- --refresh-dependencies refreshs the state of dependencies. This option replaces the deprecated --refresh dependencies option.
- --rerun-tasks forces tasks to be executed and ignore previously cached task results. This option replaces the deprecated --no-opt option.
Classpath changes for test process
In order to satisfy the requirements of the --javaagent switch and the java.system.class.loader system property we had to make some changes to the way we initialise the JVM that runs tests (tests are always executed in a separate JVM). Previously, we were starting the JVM with a minimal classloader, adding necessary jars to the system classloader programmatically after the JVM had started. Since these jars weren't available at JVM startup, the classes couldn't be referenced in --javaagent or -Djava.system.class.loader.
To address this problem, we are now starting the test JVM with all of the required jars in the classpath at startup. This introduces a different problem; Windows limits the command-line length and in many cases the test command line would be too long when all of the dependent jars are included. To workaround this limitation, we are listing the required jars in the Class-Path manifest attribute of an otherwise empty jar file. We then include this 'classpath-only' jar file in the JVM classpath. Java will load all of the required jars into the system classloader.
If you have java code that looks for a particular jar file on the classpath (by reading the java.class.path system property, or by iterating over URLs from the URLClassLoader.getURLs(), then this code will need to look for jars loaded via manifest Class-Path entries as well.
Migration
See Gradle 1.0-rc-1 Migration Guide
