Gradle Basics for Building Scripts

This article introduces and learns about Gradle as a whole, understanding concepts such as Task, Project, and some common operations for building projects using Gradle. The main content is as follows:

Setting file
Build file
Project and Tasks
Task creation
Task dependencies
Interaction between tasks
Custom properties
Summary

Setting file#

Let's talk about the Setting file for building projects with Gradle. This file is mainly used to configure the current project. For example, in Android development, a project may have multiple sub-modules. When a certain sub-module is not needed, you can remove its configuration in the Setting file. Only the sub-modules configured in the Setting file will be built. This applies not only to Android development, but also to any project built with Gradle. Setting is the default configuration file name for Gradle projects. Let's do a simple test with the Setting.gradle file. The test project directory is as follows:

├─GradleSetting
│  ├─.gradle
│  │  ├─4.1
│  │  │  ├─fileChanges
│  │  │  ├─fileHashes
│  │  │  └─taskHistory
│  │  └─buildOutputCleanup
│  └─test
│      └─Method
│          └─.gradle
│              ├─4.1
│              │  ├─fileChanges
│              │  ├─fileHashes
│              │  └─taskHistory
│              └─buildOutputCleanup
│ build.gradle
│ setting.gradle

In the project named GradleSetting, there is a sub-project called Method in the test folder. We will use the setting.gradle file to include the Method sub-project in GradleSetting. The content of the setting.gradle file is as follows:

println "---------test----Setting.gradle----------"
// Output the current project directory
println(rootDir)
// Specify the sub-project to participate in the build
include ':Method'
project(':Method').projectDir = new File(rootDir,'test/Method')

Let's take a look at the output:

PS E:\Gradle\study\GradleSetting> gradle testGradleSetting
---------test----Setting.gradle----------
E:\Gradle\study\GradleSetting

> Configure project :
testGradleSetting

> Configure project :Method
3
3
30
Get the result of the method: 30
1
2
3
4
5


BUILD SUCCESSFUL in 2s

Because Method is configured in the setting.gradle file, Method is indeed included in the build. If you remove the configuration in the setting.gradle file, Method will not be built. It is recommended to verify it yourself.

The location of the Method sub-project is configured in the setting.gradle file. If not specified, it will default to the same level as the setting.gradle file.

Build file#

If you choose to build a project using Gradle, each project will have a build.gradle file, which is the entry point for project building and applies to the entire project. You can configure common settings for sub-projects in the root project, such as configuring the repository for sub-projects to jcenter, so that all dependencies in the sub-projects will be downloaded from the jcenter repository. Here is a reference code:

// Configure the repository for sub-projects
subprojects{
	repositories{
		jcenter()
	}
}

// Configure all projects
allprojects{
	
}

...

The purpose of this section is to understand the role of the build.gradle file. In actual development, there will be more detailed configuration strategies for different types of projects.

Project and Tasks#

In Gradle, there are many Projects. You can package a Project into a jar and provide it to another Project for use. Each Project is a sub-module abstracted based on its business requirements, and is ultimately built into a complete project using Gradle.

Each Project can have multiple tasks. A Task is a unit of work that completes a specific functionality, such as the wrapper task that creates the wrapper file.

Task creation#

You should already be familiar with task creation. Let's create a task using the task keyword:

//1. Create a task
task createTask{
	doFirst{
		println 'doFirst'
	}

	doLast{
		println 'doLast'
	}
}

//2. Create a task using TaskContainer, which is already defined in Project as tasks
tasks.create("createTask1"){
	doFirst{
		println 'doFirst'
	}

	doLast{
		println 'doLast'
	}
}

The task keyword is used to create a task. In fact, task is a method in Project. In Groovy, parentheses on method parameters can be omitted, and the content in curly braces is a closure that configures the task. doFirst and doLast are two commonly used methods in Task, which will be executed at the beginning and end of the task, respectively.

Task dependencies#

Tasks can depend on each other, controlling the execution order of tasks. For example, task A must be executed before task B. In this case, task A depends on task B. Here is an example:

// Single task dependency: specify the task to depend on using dependsOn
task B(dependsOn: A){
	doFirst{
		println 'B'
	}
}

task C{
	doFirst{
		println 'C'
	}
}

// Multiple task dependencies
task D{
	dependsOn A, C
	doFirst{
		println 'D'
	}
}

Let's see the result of executing the task with multiple dependencies, gradle D:

PS E:\Gradle\study\GradleSetting> gradle D

> Task :A
A

> Task :C
C

> Task :D
D

BUILD SUCCESSFUL in 2s

Clearly, when executing task D, the other two tasks it depends on are executed first, controlling the execution order of tasks.

Note: The script is executed in order. If tasks A and C are defined after task D, an error will occur when executing task D.

Interaction between tasks#

Each created task has its own name and type Task. Therefore, we can control the execution of tasks by using the Task API. The principle of operating tasks using their names is that when creating a task, Project has already declared the corresponding task as a property of the Project object with the type Task. Here is a test code:

// Interaction between tasks
task E{
	println 'hello e'
	println "Is E a property of Project: "+project.hasProperty('E')
}

E.doFirst{
	println 'doFirst'
}

E.doLast{
	println 'doLast'
}

The result of executing the above code is:

PS E:\Gradle\study\GradleSetting> gradle E

> Configure project :
hello e
Is E a property of Project: true

> Task :E
doFirst
doLast


BUILD SUCCESSFUL in 1s

Custom properties#

Both Project and Task allow users to add additional custom properties by using the corresponding ext property. After adding, these custom properties can be read and set through the ext property. If you want to add multiple custom properties at the same time, you can use the ext block. Here is an example of defining custom properties:

apply plugin:"java"

// Custom single property
ext.name1 = "Gradle"
// Custom multiple properties
ext{
	age = 10
	score = 100
}

// Use custom properties in SourceSet
sourceSets.all{
	ext.resourceDir = null
}

// Configure custom properties
sourceSets{
	main{
		resourceDir = "main/res"
	}
	test{
		resourceDir = "test/res"
	}
}

task customProperty{
	println "name=${name1}"
	println "age=${age}"
	println "score=${score}"

	sourceSets.each {
		println "${it.name} resourceDir is ${it.resourceDir}"
	}
}

The result of executing the above code is:

PS E:\Gradle\study\GradleSetting> gradle customProperty

> Configure project :

name=Gradle
age=10
score=100
main resourceDir is main/res
test resourceDir is test/res

BUILD SUCCESSFUL in 2s

Custom properties have a wider scope than local variables and can be accessed across tasks and projects as long as the objects that these properties belong to can be accessed. In Android development, custom properties can be used to define version numbers, version names, and versions of third-party libraries used in a separate gradle file, which can be accessed by each module, making it easy to manage dependency versions and improve work efficiency to some extent.

Summary#

Gradle scripts are based on Groovy, and Groovy is fully compatible with Java syntax. Gradle scripts are essentially code, and you can use relevant syntax in Gradle to achieve the desired functionality. The following are articles in the Gradle series: