Gradle 1.7 is the fastest Gradle ever. Significant performance optimizations have been made, particularly in the areas of dependency resolution and build script compilation. All users of Gradle will benefit from these improvements, while large builds stand to gain the most. Improving performance and scalability continues to be a pervasive theme in the evolution of Gradle and 1.7 delivers on this.
In addition to these behind the scenes improvements, Gradle 1.7 is also packed with many exciting new features. The new finalizer task mechanism makes it possible to run a task after another task, regardless of its outcome. This is extremely useful for integration testing where resources (such as application servers) must be shutdown after (possibly failing) tests. Another long awaited feature, the ability to control processing of duplicate files in copy and archive creation operations, has also been added in this release.
The improvements to the Build Setup plugin in Gradle 1.7 build upon the existing functionality (i.e. converting Maven projects to Gradle) to add support for generating projects from a template. Over time this mechanism will be expanded to include custom templates, easing the process of creating a new Gradle project of a certain type.
This release of Gradle also includes major steps forward for building native binaries from C++ source. Support for native binaries in general is an area under heavy development. Expect to see Gradle's capabilities in this area continue to improve in upcoming releases.
Excitingly, Gradle 1.7 contains more contributions from developers outside of the core development team than any other release. This is a steadily increasing trend release on release and is adding significant value to Gradle for all Gradle users. Thank you to all who contributed to Gradle 1.7.
For more information on what's new in Gradle 1.7, please read on.
Test task implements standard Reporting interfaceConfigureableReport renamed to ConfigurableReportHere are the new features introduced in this Gradle release.
Gradle 1.7 is the fastest version of Gradle yet. Here are the highlights:
As always, the performance improvements that you actually see for your build depends on many factors.
With this change, the dependency resolution is much faster. Typically, the larger the project is the more configurations and dependencies are resolved during the build. By caching the artifact meta-data in memory Gradle avoids parsing the descriptor when the same dependency is requested multiple times in a build.
An incremental build for a large project should be tangibly faster with Gradle 1.7. A full build may be much faster, too. The level of performance improvement depends on the build. If a large portion of the build time is taken by slow integration tests, the performance improvements are smaller. Nevertheless, some of the large builds that were used for benchmarking show up to 30% speed increase.
Caching the artifact metadata in-memory is very important for local repositories, such as mavenLocal() and for resolution of snapshots / dynamic versions. Prior to Gradle 1.7, every time a local dependency was resolved, Gradle would load the dependency metadata directly from the local repository. With the in-memory caching of dependency metadata, this behavior now changes. During a single build, a given dependency will be loaded once only and will not be reloaded again from the repository.
This may be a breaking change for builds that depend the on the fact that certain dependencies are reloaded from the repository during each resolution. Bear in mind that the vast majority of builds will enjoy faster dependency resolution offered by the in-memory caching. If your project requires reloading of snapshots or local dependencies during the build please let us know so that Gradle can better understand your scenario and model it correctly.
To avoid increased heap consumption, the in-memory dependency metadata cache may clear the cached data when there is heap pressure.
This change improves the mechanism that Gradle uses to coordinate multi-process access to the Gradle caches. This new mechanism means that the Gradle process now requires far fewer operations on the file system and can make better use of in-memory caching, even in the presence of multiple Gradle processes accessing the caches concurrently.
The caches used for dependency resolution and for incremental build up-to-date checks are affected by this change, meaning faster dependency resolution and incremental build checks.
Coupled with this change are some improvements to the synchronization of worker threads within a given Gradle process, which means parallel execution mode is now more efficient.
The new mechanism is biased to the case where a single Gradle process is running on a machine. There should not be any performance regressions when multiple Gradle processes are used, but please raise a problem report via the Gradle Forums if you observe a regression.
This change improves build script compilation by adding some caching in critical points in the classloader hierarchy. This affects, for example, first time users of a build, build authors, and those upgrading a build to a new Gradle version.
Gradle 1.7 introduces a new task ordering rule that allows a task to finalize some other task. This feature was contributed by Marcin Erdmann.
Finalizer tasks execute after the task they finalize, and always run regardless of whether the finalized task succeeds or fails. Tasks declare the tasks that finalize them.
configure([integTest1, integTest2]) {
dependsOn startAppServer
finalizedBy stopAppServer
}In this example, it is declared that the integTest1 and integTest2 tasks are finalized by the stopAppServer task. If either of these tasks are executed during a build, the declared finalizer task will be automatically executed after this. If both tasks are executed during a build, the finalizer task will be executed after both tasks have been executed. The finalizer task, stopAppServer, does not need to be declared as a task to be run when invoking Gradle.
Finalizer tasks can be used to clean up resources, produce reports, or perform any other mandatory function after a task executes regardless of whether it succeeds or fails.
Gradle has had basic support for C++ projects for some time. This is now expanding with the goal of positioning Gradle as the best build system available for native code projects.
This includes:
Some of these features are included in Gradle 1.7 (see below), while others can be expected in the upcoming releases.
A key part of improving C++ support is an improved component model which supports building multiple binary outputs for a single defined native component. Using this model Gradle can now produce both a static and shared version of any library component.
For any library declared in your C++ build, it is now possible to either compile and link the object files into a shared library, or compile and archive the object files into a static library (or both). For any library 'lib' added to your project, Gradle will create a 'libSharedLibrary' task to link the shared library, as well as a 'libStaticLibrary' task to create the static library.
Please refer to the User Guide chapter and the included C++ samples for more details.
Each binary to be produced from a C++ project is associated with a set of compiler and linker command-line arguments, as well as macro definitions. These settings can be applied to all binaries, an individual binary, or selectively to a group of binaries based on some criteria.
binaries.all {
// Define a preprocessor macro for every binary
define "NDEBUG"
compilerArgs "-fconserve-space"
linkerArgs "--export-dynamic"
}
binaries.withType(SharedLibraryBinary) {
define "DLL_EXPORT"
}Each binary is associated with a particular C++ tool chain, allowing settings to be targeted based on this value.
binaries.all {
if (toolChain == toolChains.gcc) {
compilerArgs "-O2", "-fno-access-control"
linkerArgs "-S"
}
if (toolChain == toolChains.visualCpp) {
compilerArgs "/Z7"
linkerArgs "/INTEGRITYCHECK:NO"
}
}More examples of how binary-specific settings can be provided are in the user guide.
The C++ plugins now support using g++ when running Gradle under Cygwin.
The incremental build support offered by the C++ plugins has been improved in this release, making incremental build very accurate:
It is now even easier to obtain JVM dependencies from Bintray's JCenter Repository, with the jcenter() repo notation. JCenter is a community repository, that is free to publish to via Bintray.
repositories {
jcenter()
}This will add http://jcenter.bintray.com to your repository list, as an Apache Maven repository.
Gradle 1.7 adds the ability to specify fine grained configuration of how certain files should be copied by targeting configuration with “Ant Patterns”. This feature was contributed by Kyle Mahan.
Gradle has a unified API for file copying operations, by way of CopySpec, which includes creating archives (e.g. zips). This new feature makes this API more powerful.
task copyFiles(type: Copy) {
from "src/files"
into "$buildDir/copied-files"
// Replace the version number variable in only the text files
filesMatching("**/*.txt") {
expand version: "1.0"
}
}The filesMatching() method can be called with a closure and configures an instance of FileCopyDetails. There is also an inverse variation, filesNotMatching(), that allows configuration to be specified for all files that do not match the given pattern.
When copying files or creating archives, it is possible to do so in such a way that effectively creates duplicates at the destination. It is now possible to specify a strategy to use when this occurs to avoid duplicates. This feature was contributed by Kyle Mahan.
task zip(type: Zip) {
from 'dir1'
from 'dir2'
duplicatesStrategy 'exclude'
}There are two possible strategies: include and exclude.
The include strategy is equivalent to Gradle's existing behavior. For copy operations, the last file copied to the duplicated destination is used. However, a warning is now issued when this occurs. For archive creation (e.g. zip, jar), duplicate entries will be created in the archive.
The exclude strategy effectively ignores duplicates. The first thing copied to a location is used and all subsequent attempts to copy something to the same location are ignored. This means that for copy operations, the first file copied into place is always used. For archive operations, the same is true and duplicate entries will not be created.
It is also possible to specify the duplicates strategy on a very fine grained level using the flexibility of the Gradle API for specifying copy operations (incl. archive operations).
task zip(type: Zip) {
duplicatesStrategy 'exclude' // default strategy
from ('dir1') {
filesMatching("**/*.xml") {
duplicatesStrategy 'include'
}
}
from ('dir2') {
duplicatesStrategy 'include'
}
}It is now possible to Gradle Wrapper enable a project without having to create a Wrapper task in your build. That is, you do not need to edit a build script to enable the Wrapper.
To Wrapper enable any project with Gradle 1.7, simply run:
gradle wrapperThe Wrapper files are installed and configured to use the Gradle version that was used when running the task.
To customize the wrapper task you can modify the task in your build script:
wrapper {
gradleVersion '1.6'
}If there is already an explicitly defined task of type Wrapper in your build script, this task will be used when running gradle wrapper; otherwise the new implicit default task will be used.
The build-setup plugin now supports declaring a project type when setting up a build, laying the foundations for creating different types of project starting points conveniently. Gradle 1.7 comes with the java-library type, which generates:
To create a new Java library project, you can execute the following in a directory (no build.gradle needed):
gradle setupBuild --type java-librarySee the chapter on the Build Setup plugin for more info, including future directions.
It is now possible to explicitly set the identity of a publication with the new publishing plugins. Previously the identity was assumed to be the same of the project.
For a MavenPublication you can specify the groupId, artifactId and version used for publishing. You can also set the packaging value on the MavenPom.
publications {
mavenPub(MavenPublication) {
from components.java
groupId "my.group.id"
artifactId "my-publication"
version "3.1"
pom.packaging "pom"
}
}For an IvyPublication you can set the organisation, module and revision. You can also set the status value on the IvyModuleDescriptor.
publications {
ivyPub(IvyPublication) {
from components.java
organisation "my.org"
module "my-module"
revision "3"
descriptor.status "milestone"
}
}This ability is particularly useful when publishing with a different module or artifactId, since these values default to the project.name which cannot be modified from within the Gradle build script itself.
The publishing plugins now allow you to publish multiple publications from a single Gradle project.
project.group "org.cool.library"
publications {
implJar(MavenPublication) {
artifactId "cool-library"
version "3.1"
artifact jar
}
apiJar(MavenPublication) {
artifactId "cool-library-api"
version "3"
artifact apiJar
}
}While possible, it is not trivial to do the same with the old publishing support. The new ivy-publish and maven-publish plugins now make it easy.
TestNG supports parameterizing test methods, allowing a particular test method to be executed multiple times with different inputs. Previously in Gradle's test reports, parameterized methods were listed multiple times (for each parameterized iteration) with no way to differentiate the executions. The test reports now include the toString() values of each parameter for each iteration, making it easy to identify the data set for a given iteration.
Given a TestNG test case:
import org.testng.annotations.*;
public class ParameterizedTest {
@Test(dataProvider = "1")
public void aParameterizedTestCase(String var1, String var2) {
…
}
@DataProvider(name = "1")
public Object[][] provider1() {
return new Object[][] {
{"1", "2"},
{"3", "4"}
};
}
}The test report will show that the following test cases were executed:
aParameterizedTestCase(1, 2)aParameterizedTestCase(3, 4)This includes Gradle's own HTML test report and the “JUnit XML” file. The “JUnit XML” file is typically used to convey test execution information to the CI server running the automated build, which means the parameter info is also visible via the CI server.
Test task implements standard Reporting interfaceThe Reporting interface provides a standardised way to control the reporting aspects of tasks that produce reports. The Test task type now implements this interface.
apply plugin: "java"
test {
reports {
html.enabled = false
junitXml.destination = file("$buildDir/junit-xml")
}
}The Test task provides a ReportContainer of type TestReports, giving control over both the HTML report and the JUnit XML result files (these files are typically used to communicate test results to CI servers and other tools).
This brings the Test task into line with other tasks that produce reports in terms of API. It also allows you to completely disable the JUnit XML file generation if you don't need it.
The above change (Test task implements standard Reporting interface) means that the test reports now appear in the build dashboard.
Also, the buildDashboard task is automatically executed when any reporting task is executed (by way of the new “Finalizer Task” mechanism mentioned earlier).
This change facilitates better reporting of test execution on CI servers, notably Jenkins.
The JUnit XML file format is a de-facto standard for communicating test execution results between systems. CI servers typically use this file as the source of test execution information. It was originally conceived by the “JUnit Ant Tasks” that quickly appeared after the introduction of JUnit and became widely used, without a specification ever forming.
This file also captures the system output (System.out and System.err) that occurs during test execution. Traditionally, the output has been recorded at the class level. That is, output is not associated with the individual test cases (i.e. methods) within the class but with the class as a whole. You can now enable “output per test case” mode in Gradle to get better reporting.
test {
reports {
junitXml.outputPerTestCase = true
}
}With this mode enabled, the XML report will associate output to the particular test case that created it. The Jenkins CI server provides a UI for inspecting the result of a particular test case of class. With outputPerTestCase = true, output from that test case will be shown on that screen. Previously it was only visible on the page for the test class.
This is also necessary for effective use of the Jenkins JUnit Attachments Plugin that allows associating test attachments (e.g. Selenium screen shots) with test execution in the Jenkins UI.
Thanks to a contribution by Olaf Klischat, the Application Plugin now provides the ability to specify default JVM arguments to include in the generated launcher scripts.
apply plugin: "application"
applicationDefaultJvmArgs = ["-Dfile.encoding=UTF=8"]The OSGi plugin uses the Bnd tool to generate bundle manifests. The version used has changed from 1.50.0 to 2.1.0 with this release.
The most significant improvement obtained through this upgrade is the improved accuracy of generated manifests for Java code that uses the “invokedynamic” byte code instruction.
It is now possible to set enum value properties in the Gradle DSL using the name of the value as a string. Gradle will automatically convert it the string to the corresponding enum value. For example, this can be used for setting the (new in 1.7) duplicate handling strategy for file copy operations.
task copyFiles(type: Copy) {
from 'source'
into 'destination'
duplicatesStrategy 'exclude'
}The duplicatesStrategy property is being set here via the CopySpec.setDuplicatesStrategy(DuplicatesStrategy) method, which takes an enum value of type DuplicatesStrategy In the Gradle DSL, the value can be set using the (case-insensitive) name of the desired enum value.
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 2.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.
The Test task has been updated to implement the standard Reporting interface. The existing API for configuring reporting and results has now been deprecated. This includes the following methods:
disableTestReport()enableTestReport()isTestReport()setTestReport()getTestReportDir()setTestReportDir()getTestResultsDir()setTestResultsDir()All of the deprecated functionality is still available via the new Reporting mechanism.
As a significant performance optimization, Gradle now caches dependency descriptors in memory across the entire build. This means that if that dependency metadata changes during the build, the changes may not be seen by Gradle. There are no identified usage patterns where this would occur, but it is theoretically possible.
Please see the section on “Faster Gradle Builds” for more information.
Some properties of classes introduced by the JaCoCo code coverage plugin have been renamed with better names.
JacocoTaskExtension.destPath renamed to destinationFileJacocoTaskExtension.classDumpPath renamed to classDumpFileJacocoMerge.destFile renamed to destinationFileThe ConvertMaven2Gradle, GenerateBuildScript and GenerateSettingsScript classes have been removed. The respective logic is now part of the buildSetup task which has now the type SetupBuild.
The plugin creates different set of tasks, with different types and names depending on the build-setup type.
The setupWrapper task is now called wrapper.
For consistency with the maven-publish plugin, the task for generating the ivy.xml file for an Ivy publication has changed. This task is now named generateDescriptorFileFor${publication.name}Publication.
status value of IvyPublication is integration and no longer defaults to project.statusIn order to continue decoupling the Gradle project model from the Ivy publication model, the 'project.status' value is no longer used when publishing with the ivy-publish plugin.
If no status value is set on the IvyModuleDescriptor of an IvyPublication, then the default ivy status ('integration') will be used. Previously, 'release' was used, being the default value for 'project.status'.
The incubating C++ support in Gradle is undergoing a major update. Many existing plugins, tasks, API classes and the DSL have been being given an overhaul. It's likely that all but the simplest existing C++ builds will need to be updated to accommodate these changes.
If you want your existing C++ build to continue working with Gradle, you have 2 options:
ConfigureableReport renamed to ConfigurableReport incubating featureThe incubating class org.gradle.api.reporting.ConfigureableReport was renamed to org.gradle.api.reporting.ConfigurableReport as the original name was misspelled.
The test task is now skipped when there are no test classes (GRADLE-2702).
Previously, the test task was still executed even if there were no test classes. This meant that dependency resolution would occur and an empty HTML report was generated. This new behavior results in faster builds when there are no test classes. No negative impacts on existing builds are expected.
The OSGi plugin uses the Bnd tool to generate bundle manifests. The version used has changed from 1.50.0 to 2.1.0 with the 1.7 release.
While this should be completely backwards compatible, it is a significant upgrade.
Gradle now treats the configuration mapping of a dependency declaration in an Ivy descriptor file (ivy.xml) the same way as Ivy. Previously, there were a number of bugs that affected how Gradle handled configuration mappings in Ivy descriptor files.
These changes mean you may see different resolution results in Gradle 1.7 compared to previous Gradle versions, if you are using Ivy repositories.
On behalf of the Gradle community, the Gradle development team would like to thank the following people who contributed to this version of Gradle:
maxPriorityViolations setting for the CodeNarc plugin (GRADLE-1742).jcenter() repo notation for Bintray's JCenter repository.Contributions are an important part of the continuous improvement of Gradle.
If you would like to contribute to Gradle, please see gradle.org/contribute for how to start.
Known issues are problems that were discovered post release that are directly related to changes made in this release.