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.

New and noteworthy

Here are the new features introduced in this Gradle release.

Improved progress reporting

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:

How much work does the build still need to do until it is done?

What is Gradle doing during project configuration?

When I use the configure on demand feature, how many projects are configured in the current run?

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'

Executing specific tests from the command-line incubating feature

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:

Running specific test method or methods.

Running all classes from package.

Conveniently running specific tests from different test tasks.

Some examples of filtering from the terminal, using the new "--tests" command line option:

gradle test -- tests org . gradle . SomeTest . someFeature gradle test -- tests org . gradle . SomeTest gradle test -- tests org . gradle . internal * gradle test -- tests * IntegTest * ui * gradle test -- tests * UiTest integTest -- tests * WebTest * ui

It 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 ordering

Gradle 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.

Show task usage details via help task

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 ]

Incremental compile for C++ and C sources incubating feature

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:

The source file has changed

One of the header files that is included by that source file has changed (directly or transitively)

Compilation settings have changed

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.

Use Visual Studio to compile Windows Resources incubating feature

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 {} }

Fine-tuning the resources 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.

Support for GCC cross-compilers incubating feature

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.

Defining a GCC cross-compiler

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.

Fine-grained control of command-line arguments for GCC incubating feature

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.

Fine-tuning GCC command-line arguments 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.

Better auto-detection of Visual Studio and Windows SDK incubating feature

Gradle will now automatically locate and use more versions of Visual Studio and the Windows SDK for the VisualCpp tool chain.

Visual Studio 2012 & Visual Studio 2013

Windows SDK versions 7.1A, 8.0 & 8.1

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.

Dependency resolution result API provides information about project dependencies incubating feature

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.