Gradle 7 Overview
Estimated time to read: 3 minutes
From Java Development Environments and Tooling¶
What is Gradle?¶
- Convention based build tool. It has an understanding of where to find content and how it should be built.
- Uses DSL (Domain Specific Language) to describe the build. These are Groovy-based and Kotlin-based.
- Supports mutli-project builds.
- Supports and compile many languages
- Easily customisable
- Enables and supports dependency management
Comparison to other build tools¶
ANT vs Maven¶
Java has multiple build tools, historically there was ANT, then Maven being a new option. Gradle is a superset of these tools.
ANT (Another Neat Tool)¶
- XML-based Build Script
- Hard to read
- Difficult to maintain
- Extremely verbose
- Not convention based
Maven¶
- Convention based
- Supports dependency management
- Highly Extensible
- XML-based POM (Project Object Model)
- Hard to read
Gradle¶
- Build configuration uses Domain Specific Language (DSL)
- Quasi-JSON based
- Uses build.gradle
- Self-explanatory
Setting up Gradle¶
Installation of Gradle depends on the platform that we are working on.
Installing Gradle¶
There are also installers and tools which can assist in the setup of Gradle on our behalf;
gradle.org (All Platforms)¶
An installer is available from Gradle.org for multiple platforms
SDKmanager (macOS / Unix)¶
Gradle can also be installed via sdkman. This has the added advantage of sdkman also managing Java SDK versions, JRE versions and more.
sdkman can also work on Windows, however, this requires the Cygwin shell to be installed or the usage of WSLv2 (Windows Subsystem for Linux).
Homebrew (macOS)¶
- Install brew
- Run
brew install gradle
- Profit?
First Run¶
build.gradle¶
Before Gradle is run for the first time upon a project, a build file needs to be created. This can either be written in Groovy or Kotlin, both DSLs are supported by Gradle.
Note
Whilst Kotlin is newer and is a type language, meaning that IDE's will offer support based upon a schema. Groovy is usually used as a standard, at present, when it comes to build files.
The build file defines tasks such as build
, clean
, etc. Plugins are also defined within the build file.
Once the build file has been created and tasks have been defined, the tasks can be run either from an IDE or directly from the command line.
Tasks¶
Tasks have a lifecycle / phase. There is a configuration phase and an initialisation phase.
When you define a task, you can provide two methods, doFirst
and doLast
. These run at various parts of the task lifecycle.
Example¶
Groovy (build.gradle)¶
The example above is written using the Groovy DSL. Task, hello
, is defined in the first element. doLast
is then called, in this example, a new line with the contents of 'Hello World' is printed. This code block accepts any Groovy code.
Kotlin (build.gradle.kts)¶
The example above is written using the Kotlin DSL. Similarly to Groovy, a task is defined using tasks.register
, in this case "hello"
doLast
is then called and 'Hello World' is printed on a new line. This code block accepts any Kotlin code.
Running a Task¶
To run a task once it has been defined, enter the directory with the build.gradle
file and run gradle <task_name>
gradle tasks
will list all available tasks within the build file
Plugins¶
Plugins are a way of adding plugins and extending the functionality of Gradle.
Java Plugin¶
apply plugin: 'java'
applies the java plugin to Gradle within the current workspace.
This plugin adds a set of tasks that are relevant to the Java workflow. It also enables Java conventions within Gradle. For example, by convention, Gradle will look towards ./src/main/java/*
for Java source code and ./src/tests/*
for tests, as expected.
grade build
- The build
tasks creates the class for the project and a Jar file.
Appending -i
to a task will run Gradle in verbose mode with additional logging.
Gradle Wrapper¶
gradle wrapper
exports a wrapper for Gradle to the project structure.
This wrapper can be initialised by running ./gradlew build
, this stores a specific version of Gradle on the system, typically in ~/.gradle/wrapper/dists/
, which is independent from the system-wide installed version of Gradle.
This means that when building the project in the future, we can specify an exact version of Gradle that should be used for the build.