Last updated 10/06/2021
Gradle is a build automation tool for multi-language software development. It controls the development process in the tasks of compilation and packaging to testing, deployment, and publishing. Supported languages include Java (Kotlin, Groovy, Scala), C/C++, JavaScript.
Gradle builds on the concepts of Apache Ant and Apache Maven and introduces a Groovy- & Kotlin-based domain-specific language contrasted with the XML-based project configuration used by Maven. Gradle uses a directed acyclic graph to determine the order in which tasks can be run, through providing dependency management.
Gradle was designed for multi-project builds, which can grow to be large. It operates based on a series of build tasks that can run serially or in parallel. Incremental builds are supported by determining the parts of the build tree that are already up to date; any task dependent only on those parts does not need to be re-executed. It also supports caching of build components, potentially across a shared network using the Gradle Build Cache. It produces web-based build visualization called Gradle Build Scans. The software is extensible for new features and programming languages with a plugin subsystem.
Gradle is distributed as open-source software under the Apache License 2.0 and was first released in 2007.
A project represents a thing that is to be done, like deploying applications to staging environments. A Gradle project requires a set of tasks to execute.
A task refers to a piece of work performed by a build. It might be something as simple as compiling classes, creating JAR files, making Javadoc, or publishing some archives.
A build script is known as build.gradle and is located in the root directory of the project. Every Gradle build comprises one or more projects.
Gradle avoids unnecessary work by only running the tasks that need to run because their inputs or outputs have changed. You can also use a build cache to enable the reuse of task outputs from previous runs or even from a different machine (with a shared build cache).
There are many other optimizations that Gradle implements and the development team continually work to improve Gradle’s performance.
Gradle runs on the JVM and you must have a Java Development Kit (JDK) installed to use it. This is a bonus for users familiar with the Java platform as you can use the standard Java APIs in your build logic, such as custom task types and plugins. It also makes it easy to run Gradle on different platforms.
Note that Gradle isn’t limited to building just JVM projects, and it even comes packaged with support for building native projects.
Gradle takes a leaf out of Maven’s book and makes common types of projects — such as Java projects — easy to build by implementing conventions. Apply the appropriate plugins and you can easily end up with slim build scripts for many projects. But these conventions don’t limit you: Gradle allows you to override them, add your own tasks, and make many other customizations to your convention-based builds.
You can readily extend Gradle to provide your own task types or even build the model. See the Android build support for an example of this: it adds many new build concepts such as flavors and build types.
Several major IDEs allow you to import Gradle builds and interact with them: Android Studio, IntelliJ IDEA, Eclipse, and NetBeans. Gradle also has support for generating the solution files required to load a project into Visual Studio.
Build scans provide extensive information about a build run that you can use to identify build issues. They are particularly good at helping you to identify problems with a build’s performance. You can also share build scans with others, which is particularly useful if you need to ask for advice in fixing an issue with the build.
Gradle is a flexible and powerful build tool that can easily feel intimidating when you first start. However, understanding the following core principles will make Gradle much more approachable and you will become adept with the tool before you know it.
Gradle allows you to build any software because it makes few assumptions about what you’re trying to build or how it should be done. The most notable restriction is that dependency management currently only supports Maven- and Ivy-compatible repositories and the filesystem.
This doesn’t mean you have to do a lot of work to create a build. Gradle makes it easy to build common types of projects — say Java libraries — by adding a layer of conventions and prebuilt functionality through plugins. You can even create and publish custom plugins to encapsulate your own conventions and build functionality.
Gradle models its builds as Directed Acyclic Graphs (DAGs) of tasks (units of work). What this means is that a build essentially configures a set of tasks and wires them together — based on their dependencies — to create that DAG. Once the task graph has been created, Gradle determines which tasks need to be run in which order and then proceeds to execute them.
This diagram shows two example task graphs, one abstract and the other concrete, with the dependencies between the tasks represented as arrows:
Figure 1. Two examples of Gradle task graphs
Almost any build process can be modeled as a graph of tasks in this way, which is one of the reasons why Gradle is so flexible. And that task graph can be defined by both plugins and your own build scripts, with tasks linked together via the task dependency mechanism.
Tasks themselves consist of:
In fact, all of the above are optional depending on what the task needs to do. Some tasks — such as the standard lifecycle tasks — don’t even have any actions. They simply aggregate multiple tasks together as a convenience.
One last thing: Gradle’s incremental build support is robust and reliable, so keep your builds running fast by avoiding the clean task unless you actually do want to perform a clean.
It’s important to understand that Gradle evaluates and executes build scripts in three phases:
Sets up the environment for the build and determines which projects will take part in it.
Constructs and configures the task graph for the build and then determines which tasks need to run and in which order, based on the task the user wants to run.
Runs the tasks selected at the end of the configuration phase.
These phases form Gradle’s Build Lifecycle.
Well-designed build scripts consist mostly of declarative configuration rather than imperative logic. That configuration is understandably evaluated during the configuration phase. Even so, many such builds also have task actions — for example via doLast {} and doFirst {} blocks — which are evaluated during the execution phase. This is important because code evaluated during the configuration phase won’t see changes that happen during the execution phase.
Another important aspect of the configuration phase is that everything involved in it is evaluated every time the build runs. That is why it’s best practice to avoid expensive work during the configuration phase. Build scans can help you identify such hotspots, among other things.
It would be great if you could build your project using only the build logic bundled with Gradle, but that’s rarely possible. Most builds have some special requirements that mean you need to add custom build logic.
Gradle provides several mechanisms that allow you to extend it, such as:
When you want the build to do some work that an existing task can’t do, you can simply write your own task type. It’s typically best to put the source file for a custom task type in the buildSrc directory or in a packaged plug-in. Then you can use the custom task type just like any of the Gradle-provided ones.
You can attach custom build logic that executes before or after a task via the Task.doFirst() and Task.doLast() methods.
These allow you to add your own properties to a project or task that you can then use from your own custom actions or any other build logic. Extra properties can even be applied to tasks that aren’t explicitly created by you, such as those created by Gradle’s core plugins.
Conventions are a powerful way to simplify builds so that users can understand and use them more easily. This can be seen with builds that use standard project structures and naming conventions, such as Java builds. You can write your own plugins that provide conventions — they just need to configure default values for the relevant aspects of a build.
Gradle allows you to introduce new concepts into a build beyond tasks, files, and dependency configurations. You can see this with most language plugins, which add the concept of source sets to a build. Appropriate modeling of a build process can greatly improve a build’s ease of use and its efficiency.
It’s easy to view Gradle’s build scripts as executable code because that’s what they are. But that’s an implementation detail: well-designed build scripts describe what steps are needed to build the software, not how those steps should do the work. That’s a job for custom task types and plugins.
Yet there is one area in which it is useful to view a build script as executable code: in understanding how the syntax of the build script maps to Gradle’s API. The API documentation — formed of the Groovy DSL Reference and the Javadocs — lists methods and properties, and refers to closures and actions. What do these mean within the context of a build script? Check out the Groovy Build Script Primer to learn the answer to that question so that you can make effective use of the API documentation.
Topic Related Post
How SRE Teams Are Using AIOps to Transform IT Operations
Everything you need to know about DevOps
Is FinOps Certification Right for You? Assessing the Value and Benefits
NovelVista Learning Solutions is a professionally managed training organization with specialization in certification courses. The core management team consists of highly qualified professionals with vast industry experience. NovelVista is an Accredited Training Organization (ATO) to conduct all levels of ITIL Courses. We also conduct training on DevOps, AWS Solution Architect associate, Prince2, MSP, CSM, Cloud Computing, Apache Hadoop, Six Sigma, ISO 20000/27000 & Agile Methodologies.
* Your personal details are for internal use only and will remain confidential.
