DPE University is live! Learn more about Gradle Build Tool, Gradle Build Scan, Develocity and the ecosystem close

Gradle Build Tool Features

This categorized list of Gradle Build Tool features will help you understand some capabilities of Gradle Build Tool for your use cases. Check out the User Guide for reference and Gradle Build Tool Tutorials for getting started.

Table of Contents

Running Gradle Builds

These features affect developers running Gradle builds, and can be taken advantage of by anyone running Gradle.


Incremental Builds

Gradle checks between builds 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 does not need to be executed. Gradle also considers the configuration of the task as part of its input.

Build Caching

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.

Incremental Tasks

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

Incremental annotation processing significantly increases the effectiveness of incremental compilation when supported annotation processors are present.

Compiler Daemon

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.

Parallel Execution

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 dependency metadata (typically `pom.xml`) and artifacts in parallel. This is done on demand only when the artifacts are required.

Task Timeouts

Every task has a timeout property that can be used to limit its execution time. When a task reaches its timeout, its task execution thread is interrupted, allowing the build to finish.

Build Scans

Web-based Build Visualization

Understand what happened in your build via a rich web interface instead of a text console and text files. Build scans provide more information and are more effective.

Collaborative Debugging

Share build scans with colleagues to solve problems efficiently and improve things together. Share entire scans or links focused on a particular build aspect, such as a logging output line.

Extend and Customize

Add your own data to build scans as tags, values, and links. Integrate build scans into your toolchain.

Fine-grained Build Comparison [Develocity]

Build scan comparison quickly highlights differences between builds, such as dependencies and their versions, making root cause analysis much faster.

Track and Export History Across all Builds [Develocity]

Track key build metrics for all your builds, including local development builds and not just CI builds. Understand trends and export build scan data to the storage of your choosing.

Execution Options

Continuous build

When a Gradle task is run in continuous mode, Gradle automatically watches for changes in the input of this task. Whenever the input changes, the task is automatically executed. You can run multiple tasks continuously in a multi-project build.

Composite builds

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.

Task Exclusion

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.

Dry Run

Run a build to see which tasks actually get executed without executing the task actions.

Continue Execution After Failures

Builds do not stop when the first failure is encountered. This enables discovering as many failures as possible in a single build execution with a very nice aggregated error report at the end.

Fail Fast Test execution

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.

Sync Dependency Cache with Repository

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, Gradle will check if the previously downloaded artifacts are valid before downloading them again. This is done by comparing published SHA1 values in the repository with the SHA1 values for existing downloaded artifacts.

↑ Table of Contents

Authoring Gradle Builds

These features affect build authors and those responsible for developer productivity.

Build Logic is Testable Code

Groovy DSL

Ideally, a Groovy build script looks mostly like configuration, including setting some project properties, configuring dependencies, declaring tasks, etc. That configuration is based on Groovy language constructs.

Kotlin DSL

Gradle’s Kotlin DSL provides an alternative syntax to the traditional Groovy DSL with an enhanced editing experience in supported IDEs, superior content assistance, refactoring, documentation, and more.

Gradle Init Plugin

The Gradle Build Init plugin can create a new Gradle build of various types (Java application, Java library, Groovy library, Kotlin application, etc) or convert existing builds (e.g., An Apache Maven build) into Gradle builds.

Dependency Management

Transitive Dependencies

One of the main benefits of using a dependency management system is managing transitive dependencies. Gradle takes care of downloading and managing transitive dependencies.

Custom Dependency Scopes

Don't be limited by a predefined set of dependency scopes (compile, runtime, etc). Gradle allows you to define arbitrary dependency scopes. For example, for integration tests that you may model in your build, to provision toolchains you need in your build, etc.

File Based Dependencies

Not all dependencies are available from external repositories. Declaring dependencies on file system resources can be useful when managed dependencies are impractical or when migrating legacy builds.

Custom Repository Layout

Declare repositories with custom layouts. With custom layouts, you can effectively treat nearly any file system directory structure as an artifact repository.

3rd Party Dependency Cache

Dependencies from remote repositories are downloaded and cached locally. Subsequent builds use cached artifacts to avoid unnecessary network traffic.

Maven and Ivy Repository Compatible

Gradle is compatible with the POM & IVY Metadata formats and can retrieve dependencies from any Maven or IVY compatible repository. Ivy metadata is exposed to custom resolution rules, allowing you to filter on artifact branch, status, or other custom metadata information.

Native BOM support

Platform definitions, aka Maven BOM dependencies, are supported natively. This enables the import of definitions like the Spring Boot platform without needing an external plugin.

Dynamic Dependencies

Resolved dependency versions can be dynamic. Gradle supports the Maven snapshot mechanism but is more powerful than that. You can declare a dependency on the latest release, the most current development version, or even the latest 8.X build.

Dynamic Dependency Locking

Allow builds to remain deterministic and reproducible when using dynamic dependency versions.

Dynamic Dependencies Selection Rules

Define custom rules to select a specific version when a dynamic dependency is declared. The rules can be based on names and versions and extended metadata like branch or status. The rules can also differ based on the environment in which the build is happening, e.g., local or CI.

Dependency Version Alignment

Dependency alignment allows different modules in a logical group (Jackson modules, for example) to be aligned to the same version.

Version Conflict Resolution

Gradle resolves conflicts to the newest requested version by default. You can customize this behavior.

Substitution of Compatible Libraries

Use dependency substitution rules to specify which dependency to use. For instance, you can instruct Gradle to resolve conflicts by selecting the latest version of log4j or log4j-over-slf4j. This is particularly useful in cases where libraries like spring-all and spring-core are present in the dependency graph. Without proper management, your application's behavior can depend on the fragile classpath order.

Enhanced Metadata Resolution Support

You can adjust dependency metadata after Gradle downloads repository metadata but before it selects the resolved version. This flexibility enables the creation of custom rules for declaring modules as changing (snapshot) versions or using a custom status scheme.

Replacement of external and project dependencies

Dynamically replace external dependencies for project dependencies and vice versa. This is especially helpful when only a subset of your modules are checked out locally.

Standardizing Gradle Across Teams

Self-Provisioning Build Environment

With the Gradle wrapper, the Gradle build environment is auto-provisioned. Furthermore, you can determine which version should be used to build your project.

Version Controlled Build Environment Configuration

Important parameters for configuring the build environment can be stored in version as part of your project. No need for the developers to set them up manually. This includes the Gradle version to be used, the configuration for the JVM running the build, and the JDK for running the build.

Custom Distributions

Every Gradle distribution has an init.d directory in which you can put custom scripts that pre-configure your build environment. You can use this to apply enforced custom rules, provide built-in setup tasks for developers, and more. Together with the Gradle wrapper, you can easily distribute those custom distributions.

Software Domain Modeling

Domain Object Containers

Every domain object describing your build, be it repositories, source directories, plugins, or dependencies, is stored in a responsive container that you can register a listener with. You have full control over what particular build scripts add to a build. Augment or modify what has been added, let the build fail, or issue a warning. For example, you can define dependencies that are only added if a build adds a particular plugin.

Publishing Multiple Artifacts

Gradle can publish multiple artifacts per project with different metadata. Be it an API and an implementation jar, a library and a test fixture, or variants for different Java platforms.

Advanced Task Ordering

Beyond having full control of the dependencies created between tasks, Gradle has powerful language constructs to describe execution order between tasks, even if those tasks do not depend on each other's output. This can be modeled with shouldRunAfter and mustRunAfter relationships.

Task Dependency Inference

Gradle objects are aware of which tasks produce certain content. For example, the object representing the Java binary directory knows that the compile task produces the binaries. Any task with the Java binary directory as an input will automatically depend on the compile task. It does not need to be declared manually. This makes the build easier to maintain and more robust.

Task Finalizers

Tasks can be assigned to finalize other tasks similar to a finalizer clause in Java. These special tasks always run after another task is executed, regardless of whether this task fails or not. This can be very powerful when doing lifecycle management for containers or databases.

Dynamic Task Creation

Sometimes you want a task whose behavior depends on a large or infinite number value range of parameters. Creating task rules is a very nice and expressive way to provide such tasks.

Fine-Grained Build Event Listener

Gradle allows you to hook into every part of the build configuration and execution lifecycle for injecting custom behavior, extracting information, adding additional logging, and tons of other use cases.

User-Based Behavior Injection

You can put custom listeners into your Gradle user home that hook into every Gradle build executed on your machine. With the lifecycle listeners described above, you can add custom behavior to individualize your build experience. For example, adding and configuring the Gradle announcement plugin that pops up a window when the build finishes or adding a repository you use personally.

Per Build Behavior Injection

Similar to user-based behavior injection, you can specify additional listeners that hook into a build on the command line. For example, this can be very helpful if you want your CI build to have specific behavior (e.g., fail if a non-standard repository is used).

Gradle Plugin Authoring

TestKit for Functional Testing

Programmatic execution of build through API agnostic of test framework. Inspection of build outcome and output. Cross-version compatibility testing. Debugging the build under test from the IDE.

Custom Command Line Options

The task API supports a mechanism for marking a property to automatically generate a corresponding command line parameter with a specific name at runtime.

↑ Table of Contents

Ecosystem-specific Features

Features specific to JVM, Android, C++, Swift, Objective C, and other ecosystems.

JVM Applications

Incremental Compilation for Java

Whether the source code or the classpath changes, Gradle detects all classes affected by the change and will only recompile those.

Compile Avoidance for Java

If a dependent project has changed in an ABI-compatible way (only its private API has changed), Java compilation tasks will be up-to-date.

Built-in Groovy Support

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.

Built-in Scala Support

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

The Gradle distribution includes plugins for Checkstyle, CodeNarc, PMD, JaCoCo, and other tools.

Packaging and Distribution for JARs, WARs, and EARs

Gradle comes out-of-the-box with tools to package JVM-based code into common archive files.

Publishing to Maven Repositories

Publish artifacts to Maven repositories like Bintray or Maven Central.

Publishing to Ivy Repositories

Publish artifacts to Ivy repositories with customizable directory layouts.

Ant Integration

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.

Android Applications

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.

Native Applications

Build C/C++/Obj-C/Obj-C++/Assembler

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.

Model variants of a native component

Easily model variants of a native component like support for different ABI's, OS, build types, etc.

GCC Support

Gradle supports building with GCC4 on Linux, Windows (with Cygwin and MingW), and Mac OS X.

Clang Support

Gradle supports building with Clang on Linux and Mac OS X.

MS Visual C++ Support

Gradle supports building with Microsoft's Visual C++ compiler on Windows. (VS 2010, VS 2013, and VS 2015 supported)

Generates Windows Resources

Gradle uses Microsoft's resource compiler to build Windows resource script files into your application.

Parallel Compilation

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.

Precompiled Headers

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 included in most of your source code. Precompiled headers are a compiler-specific optimization to cache an already parsed version of your headers.

Build mixed language binaries

Gradle can build separate languages (e.g., Assembler and C) and link them into a single executable or library.

CUnit Test Support

Gradle supports testing C applications with CUnit.

GoogleTest Support

Gradle supports testing C++ applications with GoogleTest.

Cached Compilation

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 considered when reusing cached compilation.

↑ Table of Contents

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

SDK for embedded usage

Provided by the Gradle Tooling API

Version agnostic

The Gradle tooling API is backward and forward-compatible. With a particular version of the Tooling API you can drive build across all Gradle versions since 1.0.

Querying for Project model

You can query Gradle for the details of a build, including the project hierarchy, project dependencies, external dependencies (including source and Javadoc jars), source directories, and tasks in each project.

Query for Build environment information

Gradle provides programmatic 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 of how 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 in build inputs (File changes) continuously trigger specified tasks to run.

Customizable Logging

Custom Logging Schemas

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.

Redirecting Output from Other Tools

The build output is very important for the build user experience. Integrating with external tools and libraries might make the console output very verbose. In Gradle System.out, the log output of Java Util Logging, Jakarta Commons Logging, and Log4j is re-routed to the Gradle logging system. You can route and define the log level on a per-tool basis.

↑ Table of Contents