Gradle 1.12 brings some nice universal performance improvements, useful new features and a slew of bug and compatibility fixes.
In the native space, improvements have been made to the Clang support as well as improved integration with Visual Studio. Gradle also now provides support for unit testing your native code via CUnit.
A considerable amount of work in this release went in to the dependency management engine, preparing for new APIs that allow more control over the dependency resolution process. The visible result of this work in Gradle 1.12 is the ability to specify rules that identify changing components (e.g. snapshots).
Another significant area of investment in 1.12 is in the area of IDE integration, via the Tooling API. Integration with IntelliJ IDEA in particular has been improved, along with general improvements that will offer tooling providers more integration capabilities. Optimizations have also been made to the parts of the codebase that deal with IDE import, making importing Gradle 1.12 projects into IDEs faster than any previous Gradle version.
Gradle 1.12 set a new high watermark for contributions. It includes contributions from 16 different people. Contributions range from documentation improvements, to Ant import improvements, to support for building large zips, to Sonar improvements, to test reporting improvements and more. Thank you to all of the contributors.
Gradle 1.12 will be the last release in the Gradle 1.x line. The next release will be Gradle 2.0. For information on what this means for you and for the future of Gradle, please see the Gradle 2.0 announcement.
Test and JavaExec processesHere are the new features introduced in this Gradle release.
The new Gradle cunit plugin provides support for compiling and executing CUnit tests in your native-binary project.
You simply need to include your CUnit test sources, and provide a hook for Gradle to register the suites and tests defined.
#include <CUnit/Basic.h>
#include "gradle_cunit_register.h"
#include "operator_tests.h"
void gradle_cunit_register() {
CU_pSuite mySuite = CU_add_suite("operator tests", suite_init, suite_clean);
CU_add_test(mySuite, "test plus", test_plus);
CU_add_test(mySuite, "test minus", test_minus);
}Gradle will then generate the required boiler-plate CUnit code, build a test executable, and run your tests.
> gradle -q runFailingOperatorsTest There were test failures: 1. /home/user/gradle/samples/native-binaries/cunit/src/operatorsTest/cunit/test_plus.c:6 - plus(0, -2) == -2 2. /home/user/gradle/samples/native-binaries/cunit/src/operatorsTest/cunit/test_plus.c:7 - plus(2, 2) == 4 BUILD FAILED
See the user guide chapter and the cunit sample (samples/native-binaries/cunit) in the distribution to learn more. Expect deeper integration with CUnit (and other native testing tools) in the future.
Component metadata rules (introduced in Gradle 1.8) can now be used to specify whether a component version is considered changing.
A changing component is expected to change over time without a change to the version number. A commonly used and well understood example of a changing component is a “-SNAPSHOT” dependency from an Apache Maven repository (which Gradle implicitly considers to be changing).
This new feature makes it possible to implement custom strategies for deciding if a component version is changing. In the following example, every component version whose group is “my.company” and whose version number ends in “-dev” will be considered changing:
dependencies {
components {
eachComponent { ComponentMetadataDetails details ->
details.changing =
details.id.group == "my.company" &&
details.id.version.endsWith("-dev")
}
}
}This feature is especially useful when dealing with Ivy repositories, as it is a generalized form of Ivy's changingPattern concept.
See ComponentMetadataHandler for more information.
The Tooling API is a mechanism for embedding Gradle and/or driving Gradle programmatically. The new ProjectPublications Tooling API model type provides basic information about a project's publications.
The following example demonstrates using the ProjectPublications model to print out the group/name/version of each publication.
def projectConnection = ...
def publications = projectConnection.getModel(ProjectPublications)
for (publication in project.publications) {
println publication.id.group
println publication.id.name
println publication.id.version
}Both publications declared in the old (artifacts block, Upload task) and new (publishing.publications block) way are reflected in the result.
The Tooling API is a mechanism for embedding Gradle and/or driving Gradle programmatically. The new BuildInvocations Tooling API model type provides information about the possible ways to invoke the build.
It provides the invokable tasks of a project, and importantly also its applicable task selectors. A task selector effectively refers to all of the tasks with a given name in a project and its child projects. For example, it is common in a multi project build for all projects to have a build task. Invoking the build via the Tooling API with the build task selector would run the build task in every project, effectively building the entire multi project build. In contrast, invoking the build with the build task would only build the root project (or which ever project is being targeted).
This new capability makes it easier for integrators to provide more powerful interfaces for invoking Gradle builds.
The HTML test report now has a dedicated tab for ignored tests, at the overview and package level. This makes it much easier to see which tests were ignored at a glance.
Thanks to Paul Merlin for this improvement.
It is now possible to build zips with the Zip64 extension, enabling the building of large zip files.
task largeZip(type: Zip) {
from 'lotsOfLargeFiles'
zip64 = true
}The zip standard does not support containing more than 65535 files, containing any file greater than 4GB or being greater than 4GB compressed. If your zip file meets any of these criteria, then the zip must be built with the zip64 property set to true (it is false by default). This flag also applies to all JARs, WARs, EARs and anything else that uses the Zip format.
However, not all Zip readers support the Zip64 extensions. Notably, the ZipInputStream JDK class does not support Zip64 for versions earlier than Java 7. This means you should not enable this property if you are building JARs to be used with Java 6 and earlier runtimes.
Thanks to Jason Gauci for this improvement.
Gradle now respects POM profiles that are active by default, during dependency resolution. More specifically, the properties, dependencies and dependency management information is now respected.
In earlier Gradle versions, it was possible to customize the GCC compiler tool chain in various ways. For example, you could use the cCompiler.executable property to specify a custom C compiler to use.
Now you can customize the Clang tool chain in exactly the same way as the GCC tool chain.
For more details see Clang and GCC.
Gradle 1.11 added support for generating Visual Studio configuration files. This feature has been improved in the following ways in Gradle 1.12:
.vs instead of the project directoryProjectNativeComponent.name instead of ProjectNativeComponent.baseNameThere were changes in IDEA project mapping related to bug reports [GRADLE-2017] and [GRADLE-2231]. Projects generated by the IDEA plugin now better map project dependencies to classpath scopes in IDEA modules.
Test and JavaExec processes incubating featureThe Test and JavaExec tasks both now support a --debug-jvm invocation time switch, which is equivalent to setting the debug property of these tasks to true.
This makes it easy, for example, to launch the application in debug mode when using the Application plugin…
gradle run --debug-jvm
This starts the JVM process in debug mode, and halts the process until a debugger attaches on port 5005. The same can be done for any Test task.
The Gradle eclipse and idea plugins are able to find and download the source artifacts for external dependencies, and link these artifacts into the generated IDE files.
In addition to the conventional classifier-based scheme for locating source and javadoc artifacts, Gradle will now recognise artifacts declared in a specific configuration of an ivy.xml file.
For an IDE project that references an external module located in an ivy repository, Gradle will now include:
sources configuration in ivy.xmljavadoc configuration in ivy.xmlsources classifier: eg. module-1.0-sources.jarjavadoc classifier: eg. module-1.0-javadoc.jarThe Gradle Wrapper is now downloaded over HTTPS. The gradle-wrapper.properties file created by the wrapper task will now specify a HTTPS URL as the location of the Gradle distribution to download.
Existing projects should consider updating the gradle/wrapper/gradle-wrapper.properties file to use https instead of http for the distributionUrl property value. No other change to the URL is necessary.
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 Tooling API is a mechanism for embedding Gradle and/or driving Gradle programmatically. It is used by IDEs and other tooling to integrate with Gradle.
If your project is building with Gradle 1.0-milestone-8 or earlier, you are strongly encouraged to upgrade to a more recent Gradle version. All versions of integrating tools released since the release of Gradle 1.2 (September 2012) should be using a Tooling API client newer than version 1.2.
The org.gradle.tooling.model.Task.getProject() method is now deprecated and can throw UnsupportedMethodException. There is no replacement as it is expected that the caller has a reference to project prior calling to this method.
The version of the Scala incremental compiler, Zinc, that Gradle uses has been upgraded to a version 0.3.0. This might be a breaking change for users who explicitly configured an early version of zinc in their build scripts. There should be very few such users, if any.
The way that skipped/ignored tests are represented in the JUnit XML output file produced by the Test task. Gradle now produces the same output, with regard to skipped tests, as Apache Ant and Apache Maven. This format is accepted, and expected, by all major Continuous Integration servers.
This change is described as follows:
testsuite element now contains a skipped attribute, indicating the number of skipped tests (may be 0)testcase (previously it was named ignored-testcase if it was a skipped test)<skipped/> element will be presentNo changes are necessary to build scripts or Continuous Integration server configuration to accommodate this change.
The ordering of Ant target dependencies is now respected when possible. This may cause tasks of imported Ant builds to executed in a different order from this version of Gradle on.
Given…
<target name='a' depends='d,c,b'/>A shouldRunAfter task ordering will be applied to the dependencies so that, c.shouldRunAfter d and b.shouldRunAfter c.
This is in alignment with Ant's ordering of target dependencies and resolves a long standing Gradle enhancement request [GRADLE-1102].
If a zip file is built without the zip64 flag (new in this release) set to true that surpasses the file size and count limits of the zip format, Gradle will now fail the build. Previously, it may have silently created an invalid zip.
To allow the large zip to be correctly built, set the zip64 property of the task to true.
Test.filter(Closure)The incubating Test.filter(Closure) method introduced in 1.10 for configuring the TestFilter has been changed to be more consistent with other configuration methods. This method now accepts an Action and no longer returns the TestFilter. This change should not require any adjustments to build scripts as this method can still be called with a Closure, upon which it will be implicitly converted into an Action.
IdeaModule.singleEntryLibrariesThe property IdeaModule.singleEntryLibraries was previously declared as a Map with values of type Collection<File>. The values are in fact Iterable<File> and the type signature has been updated.
We would like to thank the following community members for making contributions to this release of Gradle.
We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.
Known issues are problems that were discovered post release that are directly related to changes made in this release.