As a prerequisite, make sure you’ve already installed the JDK with a version of 1.5 or higher. Even though some operating systems provide you with an out-of-the-box Java installation, make sure you have a valid version installed on your system. To check the JDK version, run java –version. Then you can refer to How to Install Gradle on CentOS 7 or leverage below script:
Setting Gradle’s JVM options
Now that you’re all set, you’ll implement a simple build script with Gradle. Even though most of the popular IDEs provide a Gradle plugin, all you need now is your favorite editor. Chapter 10 will discuss Gradle plugin support for IDEs like IntelliJ, Eclipse, and NetBeans.
Getting started with Gradle
Every Gradle build starts with a script. The default naming convention for a Gradle build script is build.gradle. When executing the command gradle in a shell, Gradle looks for a file with that exact name. If it can’t be located, the runtime will display a help message.
Let’s set the lofty goal of creating the typical “Hello world!” example in Gradle. First you’ll create a file called build.gradle. Within that script, define a single atomic piece of work. In Gradle’s vocabulary, this is called a task. In this example, the task is called helloWorld. To print the message “Hello world!” make use of Gradle’s lingua franca, Groovy, by adding the println command to the task’s action doLast. The method println is Groovy’s shorter equivalent to Java’s System.out.println:
As expected, you see the output “Hello world!” when running the script. By defining the optional command-line option quiet with –q, you tell Gradle to only output the task’s output.
Without knowing it, you already used Gradle’s DSL. Tasks and actions are important elements of the language. An action named doLast is almost self-expressive. It’s the last action that’s executed for a task. Gradle allows for specifying the same logic in a more concise way. The left shift operator << is a shortcut for the action doLast. The following snippet shows a modified version of the first example:
- Listing 2.1 Dynamic task definition and task chaining
A feature we’ve talked about before is Gradle’s tight integration with Ant (2). Because you have full access to Groovy’s language features, you can also print your message in a method named chant(). This method can easily be called from your task. Every script is equipped with a property called ant that grants direct access to Ant tasks. In this example, you print out the message “Repeat after me” using the Ant task echo to start the therapy session.
A nifty feature Gradle provides is the definition of dynamic tasks, which specify their name at runtime. Your script creates three new tasks within a loop (2) using Groovy’s times method extension on java.lang.Number. Groovy automatically exposes an implicit variable named it to indicate the loop iteration index. You’re using this counter to build the task name. For the first iteration, the task would be called yayGradle0.
Now running gradle groupTherapy results in the following output:
As shown in figure 2.10 Gradle executed the tasks in the correct order. You may have noticed that the example omitted the quiet command-line option, which gives more information on the tasks run.
Thanks to your group therapy, you got rid of your deepest fears that Gradle will be just another build tool that can’t deliver. In the next chapter, you’ll stand up a full-fledged Java application covering a broad range of Gradle’s core concepts. For now, let’s get more accustomed to Gradle’s command line.
Using the Command line
In the previous sections, you executed the tasks helloWorld and groupTherapy on the command line, which is going to be your tool of choice for running most examples throughout this book. Even though using an IDE may seem more convenient to newcomers, a deep understanding of Gradle’s command-line options and helper tasks will make you more efficient and productive in the long run.
Listing available tasks of a project
In the last section I showed you how to run a specific task using the gradle command. Running a task requires you to know the exact name. Wouldn’t it be great if Gradle could tell you which tasks are available without you having to look at the source code? Gradle provides a helper task named tasks to introspect your build script and display each available task, including a descriptive message of its purpose. Running gradle tasks in quiet mode produces the following output:
There are some things to note about the output. Gradle provides the concept of a task group, which can be seen as a cluster of tasks assigned to that group. Out of the box, each build script exposes the task group Help tasks(1) without any additional work from the developer. If a task doesn’t belong to a task group, it’s displayed under Other tasks (2). This is where you find the task groupTherapy (3). We’ll look at how to add a task to a task group in Chapter 4.
You may wonder what happened to the other tasks that you defined in your build script. On the bottom of the output, you’ll find a note that you can get even more details about your project’s tasks by using the --all option. Run it to get more information on them:
The --all option is a great way to determine the execution order of a task graph before actually executing it. To reduce the noise, Gradle is smart enough to hide tasks that act as dependencies to a root task (1). For better readability, dependent tasks are displayed indented and ordered underneath the root task.
In the previous examples, you told Gradle to execute one specific task by adding it as an argument to the command gradle. Gradle’s command-line implementation will in turn make sure that the task and all its dependencies are executed. You can also execute multiple tasks in a single build run by defining them as command-line parameters. Running gradle yayGradle0 groupTherapy would execute the task yayGradle0 first and the task groupTherapy second.
Tasks are always executed just once, no matter whether they’re specified on the command line or act as a dependency for another task. Let’s see what the output looks like:
No surprises here. You see the same output as if you’d just run gradle groupTherapy. The correct order was preserved and each of the tasks was only executed once.
TASK NAME ABBREVIATION
One of Gradle’s productivity tools is the ability to abbreviate camel-cased task names on the command line. If you wanted to run the previous example in the abbreviated form, you’d just have to type gradle yG0 gT. This is especially useful if you’re dealing with very long task names or multiple task arguments. Keep in mind that the task name abbreviation has to be unique to enable Gradle to identify the corresponding task.
EXCLUDING A TASK FROM EXECUTION
Sometimes you want to exclude a specific task from your build run. Gradle provides the command-line option –x to achieve that. Let’s say you want to exclude the task yayGradle0:
Gradle excluded the task yayGradle0 and its dependent task startSession, a concept Gradle calls smart exclusion. Now that you’re becoming familiar with the command line, let’s explore some more helpful functions.
In this section, we explore the most important general-purpose options, flags to control your build script’s logging level, and ways to provide properties to your project. The gradle command allows you to define one or more options at the same time. Let’s say you want to change the log level to INFO using the –i option and print out any stack trace if an error occurs during execution with the option -s. To do so, execute the task groupTherapy command like this: gradle groupTherapy –is or gradle groupTherapy –i –s. As you can see, it’s very easy to combine multiple options. To discover the full set, run your build with the –h argument. I won’t go over all the available options, but the most important ones are as follows:
* -?, -h, --help:
* -b, --build-file:
* -D, --system-prop:
* -P, --project-prop:
* -i, --info:
* -s, --stacktrace:
* -q, --quiet:
When using Gradle on a day-to-day basis, you’ll find yourself having to run your build repetitively. This is especially true if you’re working on a web application. You change a class, rebuild the web application archive, bring up the server, and reload the URL in the browser to see your changes being reflected. Many developers prefer test-driven development to implement their application. For continuous feedback on their code quality, they run their unit tests over and over again to find code defects early on. In both cases, you’ll notice a significant productivity hit. Each time you initiate a build, the JVM has to be started, Gradle’s dependencies have to be loaded into the class loader, and the project object model has to be constructed. This procedure usually takes a couple of seconds. Gradle daemon to the rescue!
The daemon runs Gradle as a background process. Once started, the gradle command will reuse the forked daemon process for subsequent builds, avoiding the startup costs altogether. Let’s come back to the previous build script example. On my machine, it takes about three seconds to successfully complete running the task groupTherapy. Hopefully, we can improve the startup and execution time. It’s easy to start the Gradle daemon on the command line: simply add the option --daemon to your gradle command. You may notice that we add a little extra time for starting up the daemon as well.
Subsequent invocations of the gradle command will now reuse the daemon process. Give it a shot and try running gradle groupTherapy --daemon. Wow, you got your startup and execution time down to about one second! Keep in mind that a daemon process will only be forked once even though you add the command-line option --daemon. The daemon process will automatically expire after a three-hour idle time. At any time you can choose to execute your build without using the daemon by adding the command-line option --no-daemon. To stop the daemon process, manually run gradle --stop. That’s the Gradle daemon in a nutshell. For a deep dive into all configuration options and intricacies, please refer to the Gradle online documentation at https://docs.gradle.org/current/userguide/gradle_daemon.html .
Existing tools can’t meet the build needs of today’s industry. Improving on the best ideas of its competitors, Gradle provides a build-by-convention approach, reliable dependency management, and support for multiproject builds without having to sacrifice the flexibility and descriptiveness of your build.
In Chapter 3, I’ll show how to build a full-fledged, web-enabled application with Gradle. Starting out with a simple, standalone Java application, you’ll extend the code base by adding a web component and use Gradle’s in-container web development support to efficiently implement the solution. We won’t stop there. I’m going to show how to enhance your web archive to make it enterprise-ready and make the build transferable across machines without having to install the Gradle runtime.
* 認識 Gradle - （3）Gradle 起手式