Gradle command Line arguments
Now that you have created the first working script, it is time to explore different command-line options supported by Gradle.
You have already seen the usage of -b option to specify a build script. We'll start with --help or -h or -? to list all the options available with the Gradle command line.
$ gradle -h USAGE: gradle [option...] [task...] -?, -h, --help Shows this help message. -a, --no-rebuild Do not rebuild project dependencies. -b, --build-file Specifies the build file. -c, --settings-file Specifies the settings file. --configure-on-demand Only relevant projects are configured in this build run. This means faster build for large multi-project builds. [incubating] --continue Continues task execution after a task failure.
In the preceding output, -h or --help displays many more options. We have truncated the output.
You can execute the command on your systems and check all the options. Most of these are self-explanatory. We will discuss the usage of some of the most useful options in this section.
Now we'll add two more tasks, failedTask and test to the build.gradle script and save the file as sample_build.gradle. The task named failedTask is expected to always fail due to assertion failure and the test task is dependent on the previously created task helloGradle. A task can succeed (executing all statements in the task without any exception) or it can fail (due to any exception or error in any line of code mentioned in the task) thus stopping the execution of the script.
task failedTask << {
assert 1==2
}
task test(dependsOn: helloGradle ) << {
println 'Test case executed'
}On executing the gradle -b sample_build.gradle failedTask test command, we observe that the test task is never executed. As Gradle executes tasks sequentially as they appear on the command-line, if a task fails to execute, all the remaining tasks will be ignored.
$ gradle -b sample_build.gradle failedTask test :failedTask FAILED FAILURE: Build failed with an exception. … BUILD FAILED Total time: 6.197 secs
By default, Gradle stops the build process if any task fails to execute. This feature helps to get a quick feedback on the build process. If you do not want to stop execution of the build irrespective of any task failure and you want to continue with other tasks, then it can be done by using the --continue command-line option. This feature could be useful when we want to build a multimodule project, where some of the modules might fail due to compilation error or test failure. With the –continue option, we will get a complete status of all the modules.
$ gradle -b sample_build.gradle failedTask test --continue :failedTask FAILED :helloGradle Hello Gradle- This is your first script :test Test case executed FAILURE: Build failed with an exception.
As you can see in the preceding output, failedTask failed to execute. So the build is marked as FAILURE. However, this time the test task executed successfully. Also observe that the helloGradle task is executed before the test task. This is because we have defined the test task to be dependent on the helloGradle task. This is one of the ways you can create task dependencies. For now, don't get confused with task dependency. We will discuss the topic in detail in Chapter 3, Managing Task.
Now, what happens if the helloGradle task fails? Just add a line assert 1==2 into the helloGradle task. The assert statement forces the task to fail. When you look at the following output, you will find that the test tasks is not executed as the dependent task failed:
$ gradle -b sample_build.gradle failedTask test --continue :failedTask FAILED :helloGradle Hello Gradle- This is your first script :helloGradle FAILED FAILURE: Build completed with 2 failures.
In the preceding scenario, the test task is dependent on the helloGradle task. This means that, every time we execute the test task, the helloGradle task will be executed by default. In case you want to avoid the execution of the helloGradle task, you can use the -x or --exclude-task option.
$ gradle -b sample_build.gradle failedTask --continue test -x helloGradle :failedTask FAILED :test Test case executed
Another useful option is --dry-run or -m, which runs the build but does not execute the tasks. It is useful if you want to know the task execution order or you want to validate the script.
$ gradle --dry-run -b sample_build.gradle failedTask test --continue :failedTask SKIPPED :helloGradle SKIPPED :test SKIPPED BUILD SUCCESSFUL Total time: 4.047 secs
Note
--dry-run executes all the statements which are not part of any tasks and are defined outside of a task block. To verify this, add a println statement anywhere outside a task block definition and observe the result.
So far, you must have noticed that each output displays extra information apart from the task output and error messages. Try the command-line option -q or --quiet to display only the task output:
$ gradle -q -b sample_build.gradle failedTask --continue test Hello Gradle- This is your first script Test case executed
The options --debug (-d), --info (-i), --full-stacktrace (-S), and --stacktrace (-s) display the output with different log levels and stack traces. --debug is the most detailed log level. --full-stacktrace and --stacktrace show stack traces if the build fails with an exception. Try the previously executed command with these command-line options and observe the output:
$ gradle -d -b sample_build.gradle failedTask --continue test
Now we will explore the --daemon, --stop, and --no-daemon options. On my machine, it took around 3.6 seconds to execute the preceding script. For this simple script, most of the execution time was spent in the initialization of Gradle. When we execute a Gradle command, a new Java Virtual Machine is started, then Gradle-specific classes and libraries are loaded, and finally the actual build steps are executed. Initialization and execution of Gradle can be improved using the --daemon option. This is very useful if you are working in a test-driven development where you need to execute unit tests frequently or you need to run a particular task repeatedly.
To start a daemon, you can use the --daemon option. The daemon process automatically expires after 3 hours of idle time. To check whether the daemon is running on the system, use the ps command in the UNIX environment, or the Process explorer in Windows systems. Once you have started the daemon process, again execute the same Gradle task. You will find an improvement in the execution time.
Alternatively, you can use the gradle.properties file to set the system property org.gradle.daemon to enable the daemon. In this scenario, you don't need to specify the --daemon option when executing the tasks. To try it out, create a file called gradle.properties in the same directory where you created the sample_build.gradle file and add this line org.gradle.daemon=true. Now, run the gradle command and check whether the daemon process is running. The org.gradle.daemo is a property that we have set to configure the Gradle build environment. We'll discuss more on properties and system variables in Chapter 6, Working with Gradle.
To stop the daemon process, use the gradle --stop option. Sometimes, you may not want to execute Gradle tasks with the daemon process. Use the --no-daemon option with the task to ignore any running daemons.
$ gradle -b sample_build.gradle failedtask --continue test --daemon $ ps -ef | grep gradle root 25395 2596 46 18:57 pts/1 00:00:04 /usr/local/java/jdk1.7.0_71/bin/java ….. org.gradle.launcher.daemon.bootstrap.GradleDaemon 2.4 /home/root/.gradle/daemon 10800000 93dc0fe2-4bc1-4429-a8e3- f10b8a7291eb -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError - Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en - Duser.variant $ gradle --stop Stopping daemon(s). Gradle daemon stopped.
Although the Gradle daemon is recommended for the development environment, it might get corrupted occasionally. When Gradle executes user build scripts from multiple sources (for example, in the Continuous Integration environment), it might exhaust the daemon process and may cause memory leakage if resources are not handled properly. Therefore, it is recommended not to enable the daemon for staging or continuous integration environment. Apart from the command-line, Gradle can be executed in the Graphical User Interface (GUI) as well. In the next section, we'll discuss the graphical user interface supported by Gradle. The other important command-line options such as –D or --system-prop, -P or --project-prop will be discussed in Chapter 6, Working with Gradle, when we explore more on building Java applications with Gradle.
