Gradle Script Basics

http://blog.csdn.net/yanbober/article/details/49314255

"Craftsman Joshui http://blog.csdn.net/yanbober Reprint Please specify the source." Dot I started Android technology Exchange "
1 Background

Before you start Gradle, make sure you have a preliminary understanding of groovy scripts, especially closure rules, and if you don't know groovy then you can take a quick look at the groovy basics of Groovy Script basics, and then read this article. Please refer to the Geadle website for more information about Gradle fast dry goods. I'm sorry I'm too low.

Gradle Core is a groovy-based domain-specific language (DSL, the specific concept of groovy Scripting Basics), with very good extensibility, so whether it is a simple standalone project or a large multi-project build it can effectively improve the build task, Especially for multi-project support is very good; Gradle also provides local build capabilities, such as building a separate subproject that will build all of the sub-projects that this subproject relies on, and of course his support for remote repositories and local libraries is also in place; Oh, well, after all, you'll see where he's going.

Since Gradle core is Groovy,groovy nature and Java, it is clear that the gradle environment must rely on the JDK and groovy libraries, as follows:

JDK version must be JDK6 or above;

Because Gradle comes with the groovy library, the installed groovy is gradle ignored;

The specific Gradle environment is configured well after the following diagram:

"Craftsman Joshui Http://blog.csdn.net/yanbober Reprint Please specify the source." Dot I started Android technology Exchange " 2 Gradle DSL Basics

The essence of Gradle is the configuration script, which creates an associated object when executing a type of configuration script, such as executing a build script that creates a project object that is actually the proxy object of the Gradle. Here are the types of objects that correspond to the various types of Gradle:

Script Type	Association Object Type
Build Script	Project
Init Script	Gradle
Settings Script	Settings

The three main objects of Gradle are explained below:

Project objects: Each build.gradle is converted into a project object.

Gradle object: Created during build initialization, there is only such an object in the entire build process, and it is seldom to modify this default configuration script.

Settings objects: Each settings.gradle is converted to a Settings object.

As you can see, we can directly use the properties and methods of the associated object when we write the specified type Gradle script; Of course, each script implements the script interface, which means that we can also use the properties and methods of the script interface directly. 2-1 Build Scripts Build script (Project)

Each project to be compiled in Gradle is a project (a project object for each project's Build.gradle), and each project is built with a series of tasks, many of which are gradle supported by default.

PS: So-called we write Gradle scripts, in essence, most of the time is written in the building script build scripts, so the project and script object properties and methods such as the API is very important.

Each project object corresponds to Build.gradle one by one, which is built with the following processes:

Creates an instance of the settings type for the current project.

If the current project exists with a Settings.gradle file, the settings instance that you just created is configured with this file.

Creates a project object instance of the item hierarchy through the configuration of the settings instance.

Finally, the Build.gradle script for each project is executed using the project hierarchy projects object instance created above. 2-2 Initializing Scripts init script (Gradle) and setting Scripts Settings script (Settings)

Gradle object:

Initialization Scripts init script (Gradle) is similar to Gradle's other types of scripts, which run before the build starts, and the main purpose is to do some preparatory work for the next build script. If we need to write the init script, we can put it in the user_home/.gradle/related directory by rules. Such as:

The Gradle object of the Init script represents the allocation of gradle, and we can get the Gradle instance object by calling the Project object's Getgradle () method.

Settings object:

When you configure a project (such as a multi-project tree build), the settings instance corresponds to the Settings.gradle file one by one, which is used to configure some project settings. This file is typically placed in the root directory of the project. Such as:

2-3 Build life cycle

The Gradle build script life cycle has three major strides, as follows:

As you can see, the life cycle is actually associated with the execution flow of the build script build scripts above. With this flowchart we take a detailed look at each of the processes.

Settings.gradle file:

In addition to building a script file, Gradle also defines a settings file for the contract name (default is Settings.gradle). The file is executed during the initialization phase, and for multi-project builds it must be guaranteed to have a Settings.gradle file in the root directory, which is optional for the single project build settings file, but it is recommended to write.

Here is an example of a single project build:

Settings.gradle
println ' This is executed during the initialization phase. '
   
   
    
    1
    
    2
   
   
   
   
    
    1
    
    2
   
   

Build.gradle println ' This is executed during the configuration phase. '

Task configured {println ' This is also executed during the configuration phase. '}

Task Test << {println ' This is executed during the execution phase. '}
    Task Testboth {dofirst {println ' This is executed first during the execution phase. '
    } dolast {println ' This was executed last during the execution phase. '
   
   
    
    } println ' This was executed during the configuration phase as well. '}
    
    1 2 3 4 5 6 7 8 9 10 11
   
   
   
   
    
    12 13 14 15 16 17 18 19 20
    
    1 2 3 4 5 6 7 8 9 10 11
   
  12 13 14 15 16 17 18 19 20  

Run Build results:

> Gradle Test Testboth This is
executed during the initialization phase.
This is executed during the configuration phase.
This is also executed during the configuration phase.
This was executed during the configuration phase as well.
: Test this is executed during the execution phase
.
: T Estboth This is
executed first during the execution phase.
This was executed last during the execution phase.

BUILD successful total

time:1 secs
   
   
    
    1
    
    2
    
    3
    
    4
    
    5
    
    6
    
    7
    
    8
    
    9
    
    10
   
   
   
   
    
    1
    
    2
    
    3
    
    4
    
    5
    
    6
    
    7
    
    8
    
    9
    
    14
   
   

Gradle Multi-Project construction:

Multi-project builds always need to specify a root, each node in the tree represents a project, each project object specifies a path that represents the location in the tree, and in the settings file we can also use a set of methods to customize the build project tree.

Multi-project build of layered layouts Settings.gradle file
include ' Project1 ', ' project2:child ', ' project3:child1 '
   
   
    
    1
    
    2
   
   
   
   
    
    1
    
    2
   
   

In the example above, the path of project is used as the parameter of the include method, such as the ' project3:child1 ' parameter above specifies the project3/child1 of the physical path (project3/ Child1 is relative to the multi-project root path, which also means that ' project3 ' and ' project3:child1 ' two project are created.

Multi-project construction of flat layout settings.gradle file
includeflat ' project3 ', ' Project4 '
   
   
    
    1
    
    2
   
   
   
   
    
    1
    
    2
   
   

In the example above, the Includeflat method takes a directory name as a parameter, but it is particularly important to note that these project directories must be the sibling directory of the root directory.

Of course, the multi-project tree created in the settings file is actually described by the project descriptor, and we can modify these descriptors at any time in the settings file. As follows: