学习笔记 - 5步理解Gradle. How build execution is controlled by gradle tasks?

https://docs.gradle.org/current/userguide/tutorial_using_tasks.html#sec:projects_and_tasks
https://docs.gradle.org/current/userguide/build_lifecycle.html
这是来自官网的学习笔记，含有很多复制粘贴，链接也都贴在上面和文章超链接里了

1. Five things you need to know about Gradle

1.1 Gradle is a general-purpose build tool

The most notable restriction is that dependency management currently only supports Maven- and Ivy-compatible repositories and the filesystem. But, Gradle makes it easy to build common types of project — say Java libraries — by adding a layer of conventions and prebuilt functionality through plugins.

1.2 The core model is based on tasks

• Gradle models its builds as Directed Acyclic Graphs (DAGs) of tasks (units of work)… Once the task graph has been created, Gradle determines which tasks need to be run in which order and then proceeds to execute them.
• Almost any build process can be modeled as a graph of tasks. And that task graph can be defined by both plugins and your own build scripts
• Tasks themselves consist of:
  1. Actions
  2. Inputs
  3. Outputs

1.3 Gradle has several fixed build phases

1.3.1 Three phases

1. Initialization
   Sets up the environment for the build and determine which projects will take part in it.

2. Configuration
   Constructs and configures the task graph for the build and then determines which tasks need to run and in which order, based on the task the user wants to run.

3. Execution
   Runs the tasks selected at the end of the configuration phase.

These phases form Gradle’s Build Lifecycle.

1.3.2 Declarative vs. Imperative code

• Well-designed build scripts consist mostly of declarative configuration rather than imperative logic.
  That configuration is understandably evaluated during the configuration phase. Even so, many such builds also have task actions — for example via doLast {} and doFirst {} blocks — which are evaluated during the execution phase.
  This is important because code evaluated during the configuration phase won’t see changes that happen during the execution phase.

Declarative code: Built-in, language-agnostic DSL elements (e.g. Project.dependencies{}or Project.repositories{}) or DSLs exposed by plugins
Imperative code: Conditional logic or very complex task action implementations. (e.g. doLast {}and doFirst {})
The end goal of every build script should be to only contain declarative language elements which makes the code easier to understand and maintain. Imperative logic should live in binary plugins and which in turn is applied to the build script.

• Another important aspect of the configuration phase is that everything involved in it is evaluated every time the build runs. That is why it’s best practice to avoid expensive work during the configuration phase. Build scans can help you identify such hotspots, among other things.

这里没有很理解，像Imperative code，应该是在execution phase才被evaluate的吧，那为什么还说，为了避免configuration phase任务繁重，要避免把imperative code写在build script里呢？即使写在里面，它也不会在configuration phase被evaluate吧。是不是因为不是所有的imperative code都会在execution phase被evaluate？

1.4 Gradle is extensible in

Most builds have some special requirements that mean you need to add custom build logic.
Gradle provides several mechanisms that allow you to extend it, such as:

1. Custom task types.
2. Custom task actions.
3. Extra properties on projects and tasks.
4. Custom conventions.
5. A custom model.

1.5 Build scripts operate against an API

View Gradle’s build scripts as executable code is correct.
Understanding how the syntax of the build script maps to Gradle’s API.

2. Build Script Basics

2.1 Projects and tasks

Everything in Gradle sits on top of two basic concepts: projects and tasks.

• Every Gradle build is made up of one or more projects.
• Project: can represent a Jar, a web application, a distribution zip assembled from Jars…
  A project does not necessarily represent a thing to be built. It might represent a thing to be done, such as deploying your application to staging or production environments.

Each project is made up of one or more tasks. A task represents some atomic piece of work which a build performs.

2.2 Build script

build.gradle file == a build script, strictly, build.gradle file is a build configuration script.

build.gradle

task hello {
   
    doLast {
   
        println 'Hello world!'
    }
}

Above build script defines a single task, called hello, and adds an action to it

• Gradle’s build scripts give you the full power of Groovy and Kotlin