Chapter 4. Using the Gradle Command-
Line
This chapter introduces the basics of the Gradle command-line. You run a build using the gradle command, which you have already seen in action in previous chapters
. any of the articles mentioned. (Damn, where is the previous article!!? Did I miss something? Well, I started reading it from the installation step. It seems that it is article 4 now. Well, just find one from the samples. !)
4.1. Executing multiple tasks
You can execute multiple tasks in a single build by listing each of the tasks on the command-line. For example, the command gradle compile test will execute the compile and test tasks. Gradle will execute the tasks in the order that they are listed on the command-line, and will also execute the dependencies for each task. Each task is executed once only, regardless of how it came to be included in the build: whether it was specified on the command-line, or as a dependency of another task, or both. Let’s look at an example.
Basically, you can multitask by enumerating multiple tasks in a single build. For example, starting the compile and test tasks with gradle will execute the compile and test tasks. Gradle will execute these tasks in the order they are on the command line, and will also execute the dependent tasks of each task (this looks similar to maven and ant). Each task is executed once, regardless of how it was included in the build: whether it was specified on the command line, as a dependency of another task, or both. Let's look at an example.
Below four tasks are defined. Both dist and test depend on the compile task. Running gradle dist test for this build script results in the compile task being executed only once.
The following four tasks are declared. Both dist and test tasks depend on the compile task. Execute the build script with gradle dist test, and the result will be that the compile task is executed only once!
Example 4.1. Executing multiple tasks
build.gradle
task compile << {
println '以java的名义召唤，出来吧，来自地狱的家伙，哥斯拉！^_^`'
}
task compileTest(dependsOn: compile) << {
println 'compiling unit tests'
}
task test(dependsOn: [compile, compileTest]) << {
println 'running unit tests'
}
task dist(dependsOn: [compile, test]) << {
println 'building the distribution'
}It needs to be explained here, some children's shoes may be a little depressed when they see this, how to use this code, there is no way to start! Especially children's shoes with insufficient basic knowledge will be more confused. Students who have learned ant or javac commands should know that when executing scripts, various environment variables need to be set. For example, when java commands compile java files, you may need to set classpath. In fact, it is to let the system know where the script is. Similarly The reason, gradle should be the same, then first create a folder on your own hard disk, then create a new txt text document, copy and paste the code above and save it, and finally change the name and suffix of the txt document to build .gradle, then open the command prompt and use the cd command to switch to the directory, execute gradle test dist , and you can see the same effect as the official website.
4.2. Excluding tasks
You can exclude a task from being executed using the -x command-line option and providing the name of the task to exclude. Let’s try this with the sample build file above.
You can use the -x command operation to exclude a given name task. Let's try the example above.
Direct command line input gradle dist -x test
The official website says
You can see from the output of this example, that the test task is not executed, even though it is a dependency of the dist task. You will also notice that the test task's dependencies, such as compileTest are not executed either. Those dependencies of test that are required by another task, such as compile, are still executed.
As you can see in the output of the example, the test task is not executed, even though it is a dependent task of the dist task. You should also notice that the dependencies of the test task, such as compileTest, are not executed either. Tasks that depend on tests that are in turn depended on by another task, like compile, are still executed. (It’s really confusing. Simply put, the test task is ignored, and the dependent items of the test task are also ignored, but if some of the dependent tasks of the test are dependent on another task that is not ignored, then these dependent tasks will still be executed. .)
4.3. Continuing the build when a failure occurs
By default, Gradle will abort execution and fail the build as soon as any task fails. This allows the build to complete sooner, but hides other failures that would have occurred. In order to discover as many failures as possible in a single build execution, you can use the - -continue option.
By default, gradle will terminate the execution of the executing task once an error occurs in any of the tasks. This mechanism can help us improve the entire build process faster (after all, if an error is encountered, it will throw an error, and it will not waste time to execute it), but it will hide other errors that will occur (that is, the following may be error occurred). To catch as many errors as possible in a single build, you can use the --continue action. (In fact, it means that by default, the execution will be interrupted when an error occurs. If you want to list all errors at once, add - -continue this ghost)
When executed with - -continue, Gradle will execute every task to be executed where all of the dependencies for that task completed without failure, instead of stopping as soon as the first failure is encountered. Each of the encountered failures will be reported at the end of the build.
When executed with --continue, gradle will execute every task, all dependent tasks, and complete the build without errors, instead of stopping on the first error. Every error that occurs will be reported at the end of the build.
If a task fails, any subsequent tasks that were depending on it will not be executed, as it is not safe to do so. For example, tests will not run if there is a compilation failure in the code under test; because the test task will depend on the compilation task (either directly or indirectly).
If a task fails, any subsequent tasks and its dependent tasks will not be executed because it is not safe to do so. For example, if there is an error when compiling the code, the test will not run; because this test task depends on the compilation task (directly or indirectly) (these foreigners are a pain in the ass, so they have to add such a paragraph at the end, which is completely the same as the previous paragraph. It doesn't matter, it's still saying that a task will not be executed if it stops.)