This chapter introduces you to the basics of writing Gradle build scripts. It uses toy examples to explain basic functionality of Gradle, which is helpful to get an understanding of the basic concepts. Especially if you move to Gradle from other build tools like Ant and want to understand differences and advantages.
However, to get started with a standard project setup, you don’t even need to go into these concepts in detail. Instead, you can have a quick hands-on introduction, through our step-by-step samples.
Projects, plugins and tasks
Every Gadle build is made up of one or more projects. What a project represents depends on what it is that you doing with Gradle. For example, a project might represent a library JAR or a web application. It might represent a distribution ZIP assembled from JARs produced by other projects. A project does not necessarily represent a thing to be built. It might represent a thing to be done, such as deploying your application to staging or production environments. Don't worry if this seems a little avgue for now. Gradle's build-by-convention support adds a more concrete definition for what a project is.
The work that Gradle can do on a project is defined by one or more tasks. A task represents some atomic piece of work which a build performs. This might be compiling some classes, creating a JAR, generating Javadoc, or publishing some archives to a repository.
Typically, tasks are provided by applying a plugin so that you do have to define them yourself. Still, to give you an idea of what a task is, we will look at defining some simple tasks in a build with one project in this chapter.
Hello world
You run a Gadle build using the gradle command. The gradle command looks for a file called build.gradle in the current directory. We call this build.gradle file a build script, although strictly speaking it is a build configuration script, as we will see later. The build script defines a project and its tasks.
To try this out, create the following build script named build.gradle.
In a command-line shell, move to the containing directory and execute the build script with gradle -q hello:
What does -q do?
Most of the examples in this user guide are run with the -q command-line option. This suppresses Gradle's log messages, so that only the output of the tasks is shown. This keeps the example output in this user guide a little clearer. You don't need to use this option if you don't want to. See Logging for more details about the command-line options which affect Gradle's output.
Output of Gralde -q hello
> gradle -q hello
Hello world!
Bash
복사
Example 2. Execution of a build script
This build script defines a single task, called hello, and adds an action to it. When you run gradle hello, Gradle executes the hello task, which in turn executes the action you’ve provided. The action is simply a block containing some code to execute.
If you think this looks similar to Ant’s targets, you would be right. Gradle tasks are the equivalent to Ant targets, but as you will see, they are much more powerful. We have used a different terminology than Ant as we think the word task is more expressive than the word target. Unfortunately this introduces a terminology clash with Ant, as Ant calls its commands, such as javac or copy, tasks. So when we talk about tasks, we always mean Gradle tasks, which are the equivalent to Ant’s targets. If we talk about Ant tasks (Ant commands), we explicitly say Ant task.
Build scripts are code
Gradle’s build scripts give you the full power of Groovy and Kotlin. As an appetizer, have a look at this:
Output of gradle -q upper
> gradle -q upper
Original: mY_nAmE
Upper case: MY_NAME
Bash
복사
or
Output of gradle -q count
> gradle -q count
0 1 2 3
Bash
복사
Task dependencies
As you probably have guessed, you can declare tasks that depend on other tasks.
Output of gradle -q intro
> gradle -q intro
Hello world!
I'm Gradle
Bash
복사
To add a depdency, the corresponding task does not need to exist.
The dependency of taskX to taskY may be declared before taskY is defined. Task dependencies are discussed in more detail in Adding dependencies to a task.
Flexible task registration
The power of Groovy or Kotlin can be used for more than defining what a task does For example, you can use it to register multiple tasks of the same type in a loop.
Output of gradle -q task1
> gradle -q task1
I'm task number 1
Bash
복사
Manipulating existing tasks
Once tasks are registered, they can be accessed via an API. For instance, you could use this to dynamically add dependencies to a task, at runtime. Ant doesn't allow anything like this.
Output of gradle -q task0
> gradle -q task0
I'm task number 2
I'm task number 3
I'm task number 0
Bash
복사
Or you can add behavior to an existing task.
Output of gradle -q hello
> gradle -q hello
Hello Venus
Hello Earth
Hello Mars
Hello Jupiter
Bash
복사
The calls doFirst and doLast can be executed multiple times. They add an action to the beginning or the end of the task's actions list. When the task executes, the actions in the action list are executed in order.
Using Ant Tasks
Ant tasks are first-class citizens in Gradle
....
Default tasks
Gradle allows you to define one or more default tasks that are executed if no other tasks are specified.
Output of gradle -q
> gradle -q
Default Cleaning!
Default Running!
Bash
복사
This is equivalent to running gradle clean run. In a multi-project build every subproject can have its own specific default tasks. If a subproject does not specify default task, the default tasks of the parent are used (if defined).
External dependencies for the build script
Instead of manipulating the script classpath directly, it is recommended to apply plugins that come with their own classpath. For custome build logic, the recommendation is to use a custom plugin.
If your build script needs to use external libraries, you can add them to the script's classpath in the build script itself. You do this using the buildscript() method, passing in a block which declares the build script classpath.
The block passed to the buildscript() method configures a ScriptHandler instance. You declare the build script classpath by adding dependencies to the classpath configuration. This is the same way you declare, for example, the Java compilation classpath. You can use any of the dependency types except project dependencies.
Having declared the build script classpath, you can use the classes in your build script as you would any other classes on the classpath. The following example adds to the previous examples, and uses classes from the build script classpath.
Output of gradle -q encode
> gradle -q encode
aGVsbG8gd29ybGQK
Bash
복사
For multi-project builds, the dependencies declared with a project's buildscript() method are available to the build scripts of all its sub-projects.
Build script dependencies may be Gradle plugins. Please consult Using Gradle Plugins for more information on Gradle plugins.
Every project automatically has a buildEnvironment task of type BuildEnvironmentReportTask that can be invoked to report on the resolution of the build script dependencies.
Further Reading
This chapter only scratched the surface with what’s possible. Here are some other topics that may be interesting:
