Unleash your Java project with Gradle

This chapter gives you a clear overview of Gradle and how it works before diving into details later.

We’ll cover four key Gradle concepts:

These concepts are all you need to understand before creating simple Gradle projects.

It’s so straightforward to get started with Gradle that you can create a project in just 30 seconds. This chapter walks through every step of that process, and by the end you’ll be able to create this project yourself from scratch.

The highest-level concept in Gradle is the project, which represents the entire application you’re building.

One well-known example of a Gradle project is Spring Boot. Gradle builds Spring Boot into libraries that we can use to create our own applications.

Before we get into a demo of a Gradle project, here’s a quick overview. There’s no limit to the size of a Gradle project. It could represent the smallest microservice you can imagine which accomplishes a specific task, or a huge monolithic application.

As you go through this book you’ll encounter several Gradle projects, starting off very simple, then growing slightly in size and complexity.

Maybe you’re wondering practically speaking, what does a project look like? In its simplest form it consists of a project directory, and within that a single file named settings.gradle.kts. Inside that file we specify the name of the Gradle project.

Once a Gradle project has been created, you can interact with it on the command line using the gradle command, which we’ll cover in detail in later lessons.

For the 30-second project we’ll work on in this chapter, we have a project directory named 30-second-project.

In there is the settings.gradle.kts file which contains the name of the project specified in quotes.

With this file in place we now have a Gradle project we can interact with.

If I run the gradle tasks command inside the project directory, we get a message Tasks runnable from root project `30-second-project' and a list of tasks available in this project.

This shows us that our project is properly setup and Gradle understands it. More details on all of this, including understanding what tasks are, is coming up in later lessons.

As you just saw, a settings.gradle.kts file in a project directory is all we need to create a Gradle project. At this point though, our simple project isn’t much fun as it doesn’t actually do anything.

When you want to start doing stuff with your project, like actually building your application, that’s when you need to add a Gradle build script. It contains the definition of how your application will get built.

When it comes to writing your build script, you have a choice of language, Groovy or Kotlin. Kotlin is the best choice for modern Gradle projects since it provides a better editing experience in the IDE. It’s also the option that Gradle recommend.

Since you define your build script as code, it’s very flexible because you can write any code logic you want to do pretty much anything. You’ll learn all the details of the build script in later lessons. For now though, let’s extend our 30-second project to illustrate a simple build script example.

In our project, we’ll create a file named build.gradle.kts, which will contain our build script written in the Kotlin programming language.

Inside this file we can write any code we want. Don’t worry if you’re not familiar with Kotlin as you’ll learn more about it later, but for now we’ll just use the println function which prints the string you pass it.

If I run the gradle command from within the project directory let’s see what happens. It says This is the 30 second project. Cool!

Likewise, in the build script I could define variables a and b, and print their sum like this.

Now when I run the gradle command we get the output 5, which is 2 plus 3.

That’s very nice, you might be thinking, but I don’t really want to have to write my entire build in code like this. No problem, because actually defining Gradle builds requires very little real coding.

In Gradle, you reuse predefined tasks, plugins, and other elements, which you configure together in the build script to seamlessly build small or large projects. By the end of this book you’ll be very familiar with all of these elements, and you’ll have the confidence to apply them in your own projects.

For now, just remember that the Gradle build script is where your build logic lives. In the rest of this chapter, you’ll be introduced briefly to two of the most important elements of the build script, tasks and plugins, as we finish creating this sample project.

Finally, if you’ve used the Maven build tool before, you’re right, the build.gradle.kts file is the equivalent of Maven’s pom.xml. As you’ll find out soon though, Gradle’s build script is a lot more flexible.

You just learnt how you can define a Gradle build script in a build.gradle.kts file, and in that file write any code you want. To start creating useful Gradle projects though, we need to use one of the components Gradle makes available to us called the task.

It represents a unit of work to get done in your build, whether that be copying files, compiling code, running tests, or anything else. Every task that’s part of your Gradle build script can be executed from the command line. Your Gradle project could consist of many tasks, and it’s up to you which ones you choose to run at any particular time.

And as you may have guessed, Gradle comes with many pre-packaged tasks which we can use directly in a build script to achieve specific outcomes. With the pre-packaged tasks, all the code logic to do whatever the task does has been written for us. We just have to define an instance of the task, and configure it how we need it. If we need to do something that isn’t supported by one of the pre-packaged tasks, we can always create our own custom tasks.

So how do we use a task in our build script? To show you how, in our build.gradle.kts file I’m going to define a task to copy a file from one location to another. We’ll use one of the pre-packaged Gradle tasks, unsurprisingly called Copy. To define an instance of this task, we’ll need only 4 pieces of information:

Once the task is defined, we’ll run it from the command line to copy the file.

Let’s go back to our project as we left it in the last lesson, and create a new file to be copied, called important-message.txt.

Within there we’ll write this extremely important message.

Now back in our build.gradle.kts file we’re going to define our task.

This creates a task called copyMessage of type Copy. We’re using from to set the source file and into to set the destination directory of the task. This task syntax will be explained in full in later lessons.

We can run this task from a command prompt within the 30-second-project with gradle copyMessage.

In the project directory we now have a build directory containing the copied important-message.txt.

In summary, that was a very simple use of the Copy task. It’s very flexible though, and can be scaled up to copy whole directories and even do token replacement within files.

Don’t worry about remembering the syntax of defining tasks right now, as we’ll cover it again many times. Later on, you’ll also learn about the other types of Gradle tasks, including the Java related tasks, as well as creating your own custom tasks.

For now, all you need to take away from this tasks introduction is that tasks do some work within your project, can be pre-packaged tasks or custom tasks, and can be executed from the command line.

You just saw how to define a task in your build script and then execute it from the command line. The last fundamental Gradle concept to introduce you to in this chapter is the Gradle plugin. Plugins allow us to automatically add helpful tasks into our Gradle project using pre-packaged code that either us, Gradle, or some 3rd party has written.

And if you’re thinking at this point that this diagram is starting to look a bit like a face, trust me, it was totally unintended!

Before we get into a practical example, here are some key points to understand about plugins.

Now it’s time for you to bring together the Gradle concepts from the last four lessons, the project, the build script, the task, and the plugin, and create your first project.

This is a practical lesson, which means you should do the below steps yourself to properly learn these concepts.

The last thing to do to finish off this chapter is an extension of the earlier practical lesson. In that lesson we built a simple Gradle project which copies theme park ride descriptions, replacing tokens with the theme park name.

In this chapter, you’re going to become proficient at interacting with Gradle through the command line and IDE. Whether you’re a developer, DevOps engineer, or any other role where you have to interact with Gradle, properly understanding that interface will allow you to do what you need to do more effectively.

By the end of this chapter, you’ll have the knowledge and practical skills to:

Here are the answers and explanations for the quizzes that appear at the end of the specified chapter.