Gradle Release Notes

Version 2.4-rc-1

The big story for Gradle 2.4 is the improved performance. While it's not unusual for a new Gradle release to be the fastest Gradle yet, Gradle 2.4 is significantly faster. Many early testers of Gradle 2.4 have reported that overall build times have improved by 20% up to 40%.

There are two main components to the improved performance; general configuration time optimizations, and the class reuse with the Gradle Daemon. As such, using the Gradle Daemon now provides an even greater performance advantage.

If you are using Gradle to build native code (e.g. C/C++), the news gets even better with the introduction of parallel compilation.

Other highlights include support for Amazon S3 dependency repositories and support for using annotation processors with Groovy code and more.

Fixed issues

Deprecations Features that have become superseded or irrelevant due to the natural evolution of Gradle become deprecated, and scheduled to be removed in the next major Gradle version (Gradle 3.0). See the User guide section on the “Feature Lifecycle” for more information. The following are the newly deprecated items in this Gradle release. If you have concerns about a deprecation, please raise it via the Gradle Forums. Setting number of build execution threads with --parallel-threads The, incubating, --parallel-threads command line switch has been superseded by the new --max-workers command line switch and synonymous org.gradle.workers.max build property. Likewise, the StartParameter.getParallelThreadCount() has also been deprecated. This setting configured parallel project execution. The --parallel-threads is still respected, until removed. If not specified, the value specified for --max-workers will be used. If you were using an invocation such as: ./gradlew build --parallel-threads=4 The replacement is now: ./gradlew build --max-workers=4 --parallel Alternatively, the following can be used, which will use the default value for --max-workers : ./gradlew build --parallel Lifecycle plugin changes The tasks build , clean , assemble and check are part of the standard build lifecycle and are added by most plugins, typically implicitly through the base or language-base plugins. Due to the way these tasks are implemented, it is possible to redefine them simply by creating your own task of the same name. This behavior has been deprecated and will not be supported in Gradle 3.0. That is, attempting to define a task with the same name as one of these lifecycle tasks when they are present will become an error just like any other attempt to create a task with the same name as an existing task.

Potential breaking changes Incompatibility with Team City 9.0.3 and earlier An internal change to Gradle test execution has broken the Gradle integration provided by JetBrains' TeamCity integration server. JetBrains have acknowledged the issue and have fixed the problem for the pending 9.0.4 release of TeamCity. Please see https://youtrack.jetbrains.com/issue/TW-40615 for more information on the problem. If you are affected by this issue, you can install a pre-release version of the Gradle plugin for TeamCity which is available via the above link. Model DSL changes There have been some changes to the behaviour of the model { ... } block: The tasks container now delegates to a CollectionBuilder<Task> instead of a TaskContainer .

container now delegates to a instead of a . The components container now delegates to a CollectionBuilder<ComponentSpec> instead of a ComponentSpecContainer .

container now delegates to a instead of a . The binaries container now delegates to a CollectionBuilder<BinarySpec> instead of a BinaryContainer . Generally, the DSL should be the same, except: Elements are not implicitly created. In particular, to define a task with default type, you need to use model { tasks { myTask(Task) { ... } }

Elements are not created or configured eagerly, but are configured as required.

The create method returns void.

method returns void. The withType() method selects elements based on the public contract type rather than implementation type.

method selects elements based on the public contract type rather than implementation type. Using create syntax fails when the element already exists.

There are currently no query method on this interface. The default version of the Scala Zinc compiler has changed from 0.3.0 to 0.3.5.3. MavenDeployer no longer uses global Maven settings.xml When publishing to a Maven repository using an Upload task (e.g. uploadArchives ) and the mavenDeployer repository type, the global Maven settings.xml file is no longer consulted. Previously, the “mirror”, “authentication” and “proxy” settings defined in the global settings.xml file were effecting publishing, making builds less portable which is no longer the case. This resolves [GRADLE-2681]. The user settings file (i.e. ~/.m2/settings.xml ) is still consulted for the location of the local repository when performing a local install (e.g. gradle install or gradle publishToMavenLocal ). PublishToMavenLocal.repository property has been removed Previously, the PublishToMavenLocal task (as used by the maven-publishing plugin) could be configured with an ArtifactRepository instance, which would specify the location to install to. The default repository was the repository that returned by RepositoryHandler.mavenLocal() . It is no longer possible to provide an arbitrary repository to this task. If you need to publish to an arbitrary repository, please use the PublishToMavenRepository task type instead. Changed default assembler executable for GCC/Clang tool chains The default tool used when turning assembler into object files is now gcc or clang instead of as .

Some arguments that were specific to as were converted to their GCC/Clang equivalents.

If you were passing arguments to the assembler, you may now need to use -Wa when passing them. Please see GCC's documentation for passing arguments to the assembler. Changes to CommandLineToolConfiguration.withArguments() usage The CommandLineToolConfiguration allows fine grained configuration of a tool execution for the native domain, for example when configuring a GccPlatformToolChain . There are changes to the semantics of the withArguments() method. The withArguments() method used to be called just before Gradle built the command-line arguments for the underlying tool for each source file. The arguments passed to this would include the path to the source file and output file. This hook was intended to capture "overall" arguments to the command-line tool instead of "per-file" arguments. Now, the withArguments() method is called once per task execution and does not contain any specific file arguments.

Any changes to arguments using this method will affect all source files. Implicit Groovy source compilation while compiling build script is now disabled The Groovy compiler by default looks for dependencies in source form before looking for them in class form. That is, if Groovy code being compiled references foo.bar.MyClass then the compiler will look for foo/bar/MyClass.groovy on the classpath. If it finds such a file, it will try to compile it. If it doesn't it will then look for a corresponding class file. As of Gradle 2.4, this feature has been disabled for build script compilation. It does not affect the compilation of “application” Groovy code (e.g. src/main/groovy ). It has been disabled to make build script compilation faster. If you were relying on this feature, please use the buildSrc feature as a replacement. Changes to Groovy compilation when annotation processors are present When annotation processors are “present” for a Groovy compilation operation, all generated stubs are now compiled regardless of whether they are required or not. This change was required in order to have annotation processors process the stubs. Previously the stubs were made available to the Java code under compilation via the source path, which meant that only classes actually referenced by Java code were compiled. The implication is that more compilation is now required for Groovy code when annotation processors are present, which means longer compile times. This is unlikely to be noticeable unless the code base contains a lot of Groovy code. If this is problematic for your build, the solution is to separate the code that requires annotation processing from the code that does not to some degree. Changes to default value for Java compilation sourcepath The source path indicates the location of source files that may be compiled if necessary. It is effectively a complement to the class path, where the classes to be compiled against are in source form. It does not indicate the actual primary source being compiled. The source path feature of the Java compiler is rarely needed for modern builds that use dependency management. The default value for the source path as of this release is now effectively an empty source path. Previously Gradle implicitly used the same default as the javac tool, which is the -classpath value. This causes unexpected build results when source accidentally ends up on the classpath, which can happen when dependencies surprisingly include source as well as binaries. This improvement was contributed by Thomas Broyer. Changes to AuthenticationSupported.getCredentials() method Due to the addition of support for AWS S3 backed repositories, some behavioral changes have been made to the AuthenticationSupported interface, which is implemented by MavenArtifactRepository and IvyArtifactRepository . The getCredentials() and credentials(Action) methods now throw an IllegalStateException if the configured credentials are not of type PasswordCredentials , now that it is possible to use different types of credentials. Changes to API of AntlrTask The AntlrTask previous unnecessarily exposed the internal methods buildArguments() and evaluateAntlrResult() . These methods have been removed. Some dependencies used in Gradle have been updated. Slf4j - 1.7.7 to 1.7.10

- 1.7.7 to 1.7.10 Groovy - 2.3.9 to 2.3.10

- 2.3.9 to 2.3.10 Ant - 1.9.3 to 1.9.4 These libraries are expected to be fully backwards compatible. It is expected that no Gradle builds will be negatively affected by these changes. The default version of the corresponding tool of the following code quality plugins have been updated: The checkstyle plugin now uses version 5.9 as default (was 5.7).

plugin now uses version 5.9 as default (was 5.7). The latest checkstyle version currently available is 6.4.1 but be aware that this version is not java 1.6 compliant

Be aware that there is was a breaking change of the LeftCurly rule introduced in checkstyle 5.8 (see https://github.com/checkstyle/checkstyle/issues/247)

rule introduced in checkstyle 5.8 (see https://github.com/checkstyle/checkstyle/issues/247) The pmd plugin now uses version 5.2.3 as default (was 5.1.1).

plugin now uses version 5.2.3 as default (was 5.1.1). The findbugs plugin now uses version 3.0.1 as default (was 3.0.0).

plugin now uses version 3.0.1 as default (was 3.0.0). The codenarc plugin now uses version 0.23 as default (was 0.21). Deprecated ComponentMetadataHandler.eachComponent() has been removed This method (and all overloads) has been removed in 2.4, after being deprecated in Gradle 2.3 and superseded by the all() method. Removal of package scoped methods of LogLevel The package scoped methods of the LogLevel enumeration have been removed.