This release adds some nice command-line usability features, with the ability to run a single test method and view task help from the command-line, along with some very useful improvements to progress reporting.
A new 'should run after' task ordering rule rounds out the task execution rules added over the last several Gradle releases. These rules give you fine-grained control when you need to influence task execution.
Work on support for native languages continues with more features for C and C++ development. This release sees the introduction of incremental compilation for C and C++, plus better integration with the Visual Studio and GCC tool chains.
shouldRunAfter task orderingHere are the new features introduced in this Gradle release.
When Gradle build is invoked from the command line there is a status bar that informs about the build progress. In Gradle 1.10 the information shown in the status bar is much more useful and can give insights into:
Additionally, the progress bar now works correctly when you run a parallel build.
Examples of the progress information visible in the command line:
> Configuring > 3/34 projects > :someProject
> Building 23% > :someProject:compileJava > Resolve dependencies 'runtime'The new support for test filtering improves the way you to select tests to execute from the command-line. You can now select tests at the test method or class level, using a simple pattern. This new feature is aimed to replace the existing -Dtest.single option. It is useful for:
Some examples of filtering from the terminal, using the new "--tests" command line option:
//select specific test method
gradle test --tests org.gradle.SomeTest.someFeature
//select specific test class
gradle test --tests org.gradle.SomeTest
//select all tests from package
gradle test --tests org.gradle.internal*
//select all ui test methods from integration tests by naming convention
gradle test --tests *IntegTest*ui*
//selecting tests from different test tasks
gradle test --tests *UiTest integTest --tests *WebTest*uiIt is also possible to configure the test filter in the build script:
test {
filter {
includeTestsMatching '*SomeInterestingTest'
}
}For more information please refer to the user guide chapter on test filtering.
shouldRunAfter task orderingGradle 1.6 introduced task ordering by way of the mustRunAfter method(s) added to tasks. This release brings a new ordering mechanism: shouldRunAfter. This feature was contributed by Marcin Erdmann.
If it is specified that…
task a {}
task b {
mustRunAfter a
}Then under all circumstances Gradle will ensure that b is only executed after a has executed. However it does not imply that task b depends on task a. It is only used to order the execution if both a and b are to be executed in a given build.
The new shouldRunAfter ordering works much the same way, except that it specifies an ordering preference and not a requirement. If it is specified that…
task a {}
task b {
shouldRunAfter a
}Then Gradle will execute b after a if there is not a good reason to do otherwise. This means that use of shouldRunAfter can not create a dependency cycle and it also does not prevent the tasks executing in parallel.
For more examples please see Ordering tasks in the User Guide.
You can now run the help task with the --task commandline option to get detailed usage information for a specific task. The usage information includes task type, path, description and available command-line options.
For example, to get details about the init task you can run gradle help --task init which will give you the following output:
Detailed task information for init
Path
:init
Type
InitBuild (org.gradle.buildinit.tasks.InitBuild)
Options
--type Set type of build to create.
Description
Initializes a new Gradle build. [incubating]Gradle 1.10 introduces support for incremental compile of C++ and C source files. After an initial build, the only sources that will be recompiled in subsequent builds are those where:
No action is required to enable incremental compile. Gradle will always compile incrementally for a non-clean build.
Support for incremental compilation takes Gradle one step closer to the goal of providing a production-scale build tool for C++ and C sources. Further performance testing and tuning will be required to attain the rapid speeds that C++ developers are used to, but this new feature provides the infrastructure to make this possible.
When building native binaries with the VisualCpp tool chain, Gradle can now compile Windows Resource (.rc) files and link them into the binary. This functionality is made available by the windows-resources plugin.
apply plugin: 'cpp'
apply plugin: 'windows-resources'
libraries {
hello {}
}By default, Gradle creates a single WindowsResourceSet for each component, which will includes any sources found under src/$component.name/rc. The windows resource source directories can be configured via the associated WindowsResourceSet.
sources {
hello {
rc {
source {
srcDirs "src/main/rc", "src/common/resources"
include "**/*.rc", "**/*.res"
}
}
}
}For more details please see Windows Resources in the User Guide.
Due to the wide array of GCC cross-compilers that may be used, Gradle now gives the build author a way to supply specific configuration to use a cross-compiler. The build author defines any specific command-line arguments that are required to use the cross-compiler, as well as the target platform of any binaries that the cross-compiler produces.
Configuring a GCC tool chain as a cross-compiler involves providing a TargetPlatformConfiguration to the tool chain. Each GCC tool chain has a set of such configurations, which are queried in turn when attempting to build a binary targeting a particular platform. If the configuration indicates that the target platform is supported, then the specified arguments will be passed to the compiler, linker or other tool.
model {
toolChains {
crossCompiler(Gcc) {
addPlatformConfiguration(new ArmSupport())
}
}
}
class ArmSupport implements TargetPlatformConfiguration {
boolean supportsPlatform(Platform element) {
return element.getArchitecture().name == "arm"
}
List<String> getCppCompilerArgs() {
["-mcpu=arm"]
}
List<String> getCCompilerArgs() {
["-mcpu=arm"]
}
List<String> getAssemblerArgs() {
[]
}
List<String> getLinkerArgs() {
["-arch", "arm"]
}
List<String> getStaticLibraryArchiverArgs() {
[]
}
}Note that the current DSL is experimental, and will be simplified in upcoming releases of Gradle.
While the goal is to provide a set of tool chain implementations that 'just work', there may be times when the way that Gradle drives the underlying command-line tools does not suit your purpose. For these cases it is now possible to tweak the generated command-line arguments immediately prior to them being provided to the underlying tool.
The command-line arguments of a tool can be modified via a withArguments closure, which is provided with the full set of generated arguments as a list. The list can be changed directly, by adding, removing and replacing entries. This modified list is the used to actually drive the underlying tool.
model {
toolChains {
gcc(Gcc) {
cppCompiler.withArguments { args ->
Collections.replaceAll(args, "OPTIMISE", "-O3")
args << "extra_arg"
}
}
}
}Note that the current DSL is experimental, and will be simplified in upcoming releases of Gradle.
Gradle will now automatically locate and use more versions of Visual Studio and the Windows SDK for the VisualCpp tool chain.
Support for Visual Studio remains experimental. Please let us know via the Gradle forums if you experience problems with Gradle using your Visual Studio installation.
The ResolutionResult API provides information about a resolved graph of dependencies, such as the compile-time dependencies of a Java project. Previously, this API did not provide any way to determine which of the dependencies in the graph are produced by a project in the build and which dependencies originated outside the current build, such as from a binary repository.
The API has been extended so that you can now query whether a given dependency originated from a project in the build or not.
Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility. See the User guide section on the “Feature Lifecycle” for more information.
The following are the features that have been promoted in this Gradle release.
The following methods have been promoted and are no longer incubating:
NamedDomainObjectContainer.maybeCreate()RepositoryHandler.jcenter()As part of initial work to support more powerful dependency management, such handling native binaries, Android libraries and applications, and Scala libraries built for multiple Scala versions, the dependency resolution result API has been changed.
The dependency resolution model is now that the result of dependency resolution is a graph of components rather than module versions. A component represents things such as a Java library, or native executable and so on. This is a higher level and more general concept than a module version, which simply represents something published to a binary repository.
The main change in this release is to reflect the fact that not all dependencies of a project are published to a binary repository. For example, a component might be built by some other project in the build, or may be pre-built and installed on the local machine somewhere, or might be built by some other build tool.
ResolutionResult APIResolvedModuleVersionResult is now called ResolvedComponentResultModuleVersionSelectionReason is now called ComponentSelectionReasonComponentSelector is now used instead of ModuleVersionSelectorComponentIdentifier is now used instead of ModuleVersionIdentifierResolutionResult where renamed:
getAllModuleVersions() is now called getAllComponents()allModuleVersions() is now called allComponents()ResolutionResultDependencyResultResolvedComponentResultUnresolvedDependencyResultIn this release, the way that Gradle selects a matching version for a dynamic version, such as 1.2+ or latest.integration has changed. For the large majority of cases, the result will be the same as previous releases. However, there may be cases where this change will produce a different result.
Previously, Gradle would select a match for a dynamic version by first searching for versions that include a meta-data file, such as a pom.xml or an ivy.xml file. If any such versions were found, Gradle would select the highest version that meets the criteria and use it. If no versions were found with a meta-data file, then Gradle would search again, this time for versions without a meta-data file. Gradle would then select the highest version from these.
There are several problems with this approach: Firstly, it requires two separate repository searches, which can be a performance or stability issue, in particular when multiple repositories have to be searched. Secondly, this can give unexpected results when the module, for whatever reason, is sometimes published with meta-data and sometimes without meta-data.
In the 1.10 release, Gradle now searches once for all versions of the module and select the highest version that meets the criteria, regardless of whether the version includes a meta-data file or not.
We would like to thank the following community members for making contributions to this release of Gradle.
shouldRunAfter task ordering ruleWe 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.