Gradle study notes (3) Gradle command study (the first demo continues)

4.4. Task name abbreviation(任务名称缩写)
When you specify tasks on the command-line, you don’t have to provide the full name of the task. You only need to provide enough of the task name to uniquely identify the task. For example, in the sample build above, you can execute task dist by running gradle di

When you specify a task on the command line, you do not need to provide the full name of the task. Simply provide a unique name sufficient to identify the task. For example, in the above example, executing the dist task only requires running the gradle di command.

> gradle di
:compile
compiling source
:compileTest
compiling unit tests
:test
running unit tests
:dist
building the distribution

BUILD SUCCESSFUL

Total time: 1 secs

You can also abbreviate each word in a camel case task name. For example, you can execute task compileTest by running gradle compTest or even gradle cT

You can also find words like camel case (method and variable name naming rules in java, the first letter of each word except the first letter is capitalized, just like the camel's hump has a highest point), specify the name according to the first letter, For example, you can execute the task compileTest by executing compTest or cT. (Of course, you can also use coT, etc., just pay attention to the first letter of each word, lowercase lowercase, uppercase uppercase)

> gradle cT
:compile
compiling source
:compileTest
compiling unit tests

BUILD SUCCESSFUL

Total time: 1 secs

You can also use these abbreviations with the -x command-line option.

You can also use abbreviation rules in -x command operations. (that is, the exclude command mentioned earlier)

4.5. Selecting which build to execute

When you run the gradle command, it looks for a build file in the current directory. You can use the -b option to select another build file. If you use -b option then settings.gradle file is not used. Example:

When you execute the gradle command, it will look for the build file (build.gradle file) from the current directory. You can use the -b action to select another build file. If you use the -b action, then the settings.gradle file will not be used.
E.g:

subdir/myproject.gradle

task hello << {
    println "using build file '$buildFile.name' in '$buildFile.parentFile.name'."
}

Yesterday I created the first script build.gradle in the directory Chapter4.1. Now I create a Chapter4.2 directory at the same level of this directory, and write a myproject.gradle script file, which defines the hello task above. Currently I am still in directory 4.1,
execute the command: gradle -b ../Chapter4.2/myproject.gradle hello

write picture description here

Sure enough, this can be executed. Now it seems that this thing is the same as the general command line, and the specified directory can also be run. The command on the official website uses -q . This -q actually means quiet, which is Quiet mode, will not output unwanted content, such as BUILD SUCCESSFUL.

write picture description here

What are the specific options followed by gradle, you can type the command gradle -h to view.
write picture description here

Alternatively, you can use the -p option to specify the project directory to use. For multi-project builds you should use -p option instead of -b option.

Alternatively, you can use the -p option to specify the project directory to use. In multi-project builds, you need to use the -p option instead of the -b option.

for example:

> gradle -q -p subdir hello
using build file 'build.gradle' in 'subdir'.

write picture description here

One thing to note here, in this way, the gradle file name must be build.gradle

4.6. Obtaining information about your build

Gradle provides several built-in tasks which show particular details of your build. This can be useful for understanding the structure and dependencies of your build, and for debugging problems.

Gradle provides several built-in tasks for displaying specific details about your build. These are very useful for understanding your build structure and dependencies, and for debugging problems.

In addition to the built-in tasks shown below, you can also use the project report plugin to add tasks to your project which will generate these reports.

In addition to the built-in tasks mentioned below, you can also use the project report plugin to add tasks to your project, and those projects that add tasks will generate these reports.

Click on the hyperlink above, it turned out to be jumped to the relevant page of the project report plugin, then let's follow along to see what's going on!

Chapter 27. The Project Report Plugin

The Project report plugin adds some tasks to your project which generate reports containing useful information about your build. These tasks generate the same content that you get by executing the tasks, , and tasks from the command line (see Section 4.6, “Obtaining information about your build”). In contrast to the command line reports, the report plugin generates the reports into a file. There is also an aggregating task that depends on all report tasks added by the plugin. dependenciesproperties

We plan to add much more to the existing reports and create additional ones in future releases of Gradle.

It probably means that this plugin can add some tasks to your project for the purpose of generating some reports containing your build information. The content generated by these tasks is the same as when you execute tasks, dependencies, and properties. The difference from the command line is that the report content generated by this plugin is put into a file. The task added by this plugin is an aggregate task that depends on all report tasks.

We plan to update existing reports, and will add more of these in future releases.

27.1. Usage

To use the Project report plugin, include the following in your build script:

To use the project report plugin, you need to add the following code to your script.

apply plugin: 'project-report'

27.2. Tasks

The project report plugin defines the following tasks:

Here are some tasks currently defined by the project report plugin.

Table 27.1. Project report plugin - tasks

Task name Depends on Type Description
dependencyReport - DependencyReportTask Generates the project dependency report.
htmlDependencyReport - HtmlDependencyReportTask Generates an HTML dependency and dependency insight report for the project or a set of projects.
propertyReport - PropertyReportTask Generates the project property report.
taskReport - TaskReportTask Generates the project task report.
projectReport dependencyReport, propertyReport, taskReport, htmlDependencyReport Task Generates all project reports.

27.3. Project layout

The project report plugin does not require any particular project layout.

This thing doesn't need any specific layout.

27.4. Dependency management

The project report plugin does not define any dependency configurations.

This thing doesn't need to define any dependencies.

27.5. Convention properties

The project report defines the following convention properties:

Table 27.2. Project report plugin - convention properties

Property name Type Default value Description
reportsDirName String reports The name of the directory to generate reports into, relative to the build directory.
reportsDir File(read-only) buildDir/reportsDirName The directory to generate reports into.
projects Set<Project> A one element set with the project the plugin was applied to. The projects to generate the reports for.
projectReportDirName String project The name of the directory to generate the project report into, relative to the reports directory.
projectReportDir File(read-only) reportsDir/projectReportDirName The directory to generate the project report into.

These convention properties are provided by a convention object of type . ProjectReportsPluginConvention

These convention properties are all here ProjectReportsPluginConvention .



Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325490711&siteId=291194637