Table of Contents
Running Gradle Builds
These features affect developers running Gradle builds, and can be taken advantage of by anyone running Gradle.
Gradle checks in between build runs whether the input, output or an implementation of a task has changed since the last build invocation. If not, the task is considered up to date and is not executed. Gradle also considers the configuration of the task as part of its input.
If a task has already been executed on another computer, Gradle can skip the execution locally, and instead load the task's outputs from the build cache. The typical use case is to let CI builds push to a shared build cache, and allow developers to pull from it. A local build cache is also available to reuse task outputs produced earlier on the same machine. Several plugins including Android, Kotlin, C++, and Scala also support task level caching.
When Gradle discovers that the input or output of a task has changed between build runs, the task is executed again. The task can use the incremental API to learn what files exactly have changed. With this information the task may not need to rebuild everything.
Incremental annotation processing significantly increases the effectiveness of incremental compilation when supported annotation processors are present.
When you need to fork the compilation process, Gradle creates a daemon process that is reused within a multi project build. This provides a dramatic speed improvement for the compilation process.
Gradle allows parallel execution of tasks and intra-task work through a Worker API. Parallelism is very fine-grained, resulting in faster performance.
Parallel Download of Dependencies
Gradle will download both dependency metadata (typically `pom.xml`) and artifacts in parallel. This is done on demand, only when the artifacts are actually required.
Every task has a timeout property which can be used to limit its execution time. When a task reaches its timeout, its task execution thread is interrupted and allowing the build to finish.
Understand what happened in your build via a rich web interface instead of a text console and text files. Build scans provide more information, more effectively.
Share build scans with colleagues to efficiently solve problems and improve things together. Share entire scans or links focussed to a particular aspect of the build such as a logging output line.
Add your own data to build scans as tags, values and links. Integrate build scans into your toolchain.
Build scan comparison quickly highlights differences between builds, such as dependencies and their versions, making root cause analysis much faster.
Track key build metrics for all of your builds, including local development builds and not just CI builds. Understand trends and export build scan data to storage of your choosing.
When a Gradle task is run in continuous mode, Gradle automatically watches for changes of the input of this task. Whenever the input changes, the task it automatically executed. You can run multiple tasks continuously in a multi-project build.
Composite builds allow you to include other independent projects so that you can, for instance, develop an application and a library that it depends on simultaneously. They build in parallel by default, and can be nested.
You can exclude any task from being run. When you exclude a task, all tasks this task depends on are also automatically excluded if they have no other dependencies.
Run a build to see which tasks actually get executed without executing the task actions.
Does not stop as soon as the first failure is encountered. Executes every task to be executed where all of the dependencies for that task completed without failure. Enables discovery of as many failures as possible in a single build execution with a very nice aggregated error report at the end.
Although continuing after a test failure is the default in Gradle, you can set the `--fail-fast` flag or configure `failFast=true` for a Gradle build to fail and finish as soon as one of your tests fails.
Gradle has a `--refresh-dependencies` option to ignore all cached entries for resolved modules and artifacts. A fresh resolve will be performed against all configured repositories, with dynamic versions recalculated, modules refreshed, and artifacts downloaded. However, where possible Gradle will check if the previously downloaded artifacts are valid before downloading again. This is done by comparing published SHA1 values in the repository with the SHA1 values for existing downloaded artifacts.
Features specific to JVM, Android, C++, Swift, Objective C, and other ecosystems.
Whether a the source code or the classpath changes, Gradle detects all classes that are affected by the change and will only recompile those.
If a dependent project has changed in an ABI-compatible way (only its private API has changed), then Java compilation tasks will be up-to-date.
The Groovy plugin extends the Java plugin to add support for Groovy projects. It can deal with Groovy code, mixed Groovy and Java code, and even pure Java code.
The Scala plugin extends the Java plugin to add support for Scala projects. It can deal with Scala code, mixed Scala and Java code, and even pure Java code.
Built-in Support for JVM Code Quality Tools
Gradle comes out-of-the-box with tools to package JVM-based code into common archive files.
Publish artifacts to Maven repositories like Bintray or Maven Central.
Publish artifacts to Ivy repositories, with customizable directory layouts.
You can deeply integrate any default, optional, or custom Ant task. You can also import Ant builds at runtime, and even partially replace Ant targets dependent on Gradle tasks.
Official Android Build Tool
The Gradle Android Plugin and Android Studio are official tools provided and maintained by the Android SDK Tools team. To learn more about using Gradle with Android, please reference the Android Developer Documentation for Gradle.
Gradle has built in support for compiling and linking programs using Assembler, C/C++ and Obj-C/C++. Gradle can build shared and static libraries and executables.
Easily model variants of a native component like support for different ABI's, OS, build types, etc.
Gradle supports building with GCC4 on Linux, Windows (with Cygwin and MingW) and Mac OS X.
Gradle supports building with Clang on Linux and Mac OS X.
Gradle supports building with Microsoft's Visual C++ compiler on Windows. (VS 2010, VS 2013, and VS 2015 supported)
Gradle uses Microsoft's resource compiler to build Windows resource script files into your application.
When building native code, Gradle divides the compilation step into parallelizable tasks and executes them in a shared resource pool. This speeds up the single project case and ensures that Gradle does not consume too many resources in parallel multi-project builds.
Gradle makes it easy to use precompiled headers when building your software. Precompiled headers can speed up compilation times if your project has many header files that are included in most of your source code. Precompiled headers is a compiler-specific optimization to cache an already parsed version of your headers.
Gradle can build separate languages (e.g., Assembler and C) and link them into a single executable or library.
Gradle supports testing C applications with CUnit.
Gradle supports testing C++ applications with GoogleTest.
When building native code, Gradle uses the build cache to avoid recompiling code that hasn't changed. Compiler arguments, macro definitions and headers are all taken into account when reusing cached compilation.
Features for Developer Tool Providers
These features will be most interesting for those working on IDEs and continuous integration systems, but there are many other creative uses.
Embed Gradle with Tooling API
Provided by the Gradle Tooling API
The Gradle tooling API is back and forward compatible. With a particular version of the Tooling API you can drive build across all Gradle version since 1.0.
Querying for Project model
You can query Gradle for the details of a build, including the project hierarchy and the project dependencies, external dependencies (including source and Javadoc jars), source directories and tasks of each project.
Query for Build environment information
Gradle provides programmatically access to information about the build environment. This includes information about the Gradle Version, The Gradle User Home directory and the Java Home directory.
Execute a build
You can execute a build and listen to stdout and stderr logging and progress (e.g. the stuff shown in the 'status bar' when you run on the command line).
Build Operation Cancellation
All operations initiated via the Gradle Tooling API are gracefully cancellable at any time during the build
Support custom JVM settings
JVM args provided via the Gradle Tooling API take precedence over gradle.properties
Provide Eclipse Project Model
The Gradle Tooling API provides a model of how your project is mapped to an Eclipse project.
Provide IDEA Project Model
The Gradle Tooling API provides a model how to your project is mapped to the IDEA model.
Provide support for custom Project Model
You can write a Gradle plugin to add custom metadata for the Gradle Tooling API. You can use this for example when you integrate your own product/customizations with Gradle.
Run specific tests
The TestLauncher API allows running specific JUnit or TestNG Tests within one or more Test Tasks
Register for progress events
Register for events of task or test progress to get informed about the process of the build with rich information about the processed task and test
Run Continuous Builds
Gradle Tooling API provides the functionality to run a build programmatically in "continuous build" mode. Changes on build inputs (File changes) continuously trigger specified tasks to run.
You can replace much of Gradle’s logging UI with your own. You might do this, for example, if you want to customize the UI in some way, e.g. to log more or less information, or to change the formatting.
The build output is very important for the build user experience. If you integrate with external tools and libraries their console output might be very verbose. In Gradle System.out and log output of Java Util Logging, Jakarta Commons Logging and Log4j is re-reouted to the Gradle logging system. You can define per external tool you are integrating with to which log level the output should be routed.