Gradle Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 24: Line 24:
The build starts with the initialization phase. Gradle creates a [[Org.gradle.api.invocation.Gradle|Gradle]] instance and a [[Gradle_Settings|Settings]] instance, then executes the [[settings.gradle|settings script]], which updates the state of its [[Gradle_Settings|Settings delegate]]. In case of a simple project, Gradle creates the Project instance. For a multi-project build, and depending on which project is executed, Gradle figures out which of the project dependencies need to participate in the build. It creates a [[Gradle_Project|project representation]] for each of the projects, defining the build's project hierarchy. The sub-projects are declared using the "include" or "includeFlat" Settings methods in [[settings.gradle]]. Note that at the initialization phase, Project instances are not accessible from the settings script. Project data can be accessed via a [[Gradle_Settings_Script_and_Settings_Instance#ProjectDescriptor_-_Access_to_Projects_from_Settings|ProjectDescriptor]] interface instead.
The build starts with the initialization phase. Gradle creates a [[Org.gradle.api.invocation.Gradle|Gradle]] instance and a [[Gradle_Settings|Settings]] instance, then executes the [[settings.gradle|settings script]], which updates the state of its [[Gradle_Settings|Settings delegate]]. In case of a simple project, Gradle creates the Project instance. For a multi-project build, and depending on which project is executed, Gradle figures out which of the project dependencies need to participate in the build. It creates a [[Gradle_Project|project representation]] for each of the projects, defining the build's project hierarchy. The sub-projects are declared using the "include" or "includeFlat" Settings methods in [[settings.gradle]]. Note that at the initialization phase, Project instances are not accessible from the settings script. Project data can be accessed via a [[Gradle_Settings_Script_and_Settings_Instance#ProjectDescriptor_-_Access_to_Projects_from_Settings|ProjectDescriptor]] interface instead.


[[Gradle Extra Properties#Overview|Extra properties]] for [[Org.gradle.api.invocation.Gradle|Gradle]] and [[Gradle_Settings|Settings]] object instances can be declared at this phase. None of the build scripts is executed in this phase.
[[Gradle Extra Properties#Overview|Extra properties]] for [[Org.gradle.api.invocation.Gradle|Gradle]] and [[Gradle_Settings|Settings]] object instances can be declared at this phase. None of the build scripts is executed in this phase.


<span id='Build_Configuration_Phase'></span><span id='Configuration'></span>'''Configuration phase'''. The code declared in [[build.gradle]] is executed in order. Tasks are [[Gradle_Task#Task_Lifecycle|instantiated and configured]], by executing their [[Gradle_Task#Task_Configuration_Closure|configuration closures]]. Any configuration code is executed with every build of the project. Gradle constructs a task DAG. <font color=darkgray>The [[Gradle_Task#Incremental_Builds|incremental build]] features determines if any of the tasks in the model are required to run.</font>
<span id='Build_Configuration_Phase'></span><span id='Configuration'></span>'''Configuration phase'''. The code declared in [[build.gradle]] is executed in order. Tasks are [[Gradle_Task#Task_Lifecycle|instantiated and configured]], by executing their [[Gradle_Task#Task_Configuration_Closure|configuration closures]]. Any configuration code is executed with every build of the project. Gradle constructs a task DAG. <font color=darkgray>The [[Gradle_Task#Incremental_Builds|incremental build]] features determines if any of the tasks in the model are required to run.</font>

Revision as of 21:36, 11 October 2020

External

Internal

Overview

Gradle is a general-purpose build tool. It is primarily used to build Java and Groovy, but it can build other languages as well. The goal of a Gradle execution, also known as a Gradle build, is to execute a set of tasks, in sequence. Each build runs according to a well defined build lifecycle, during which Gradle instantiates a complex domain model of the project in memory: a Gradle instance, a Settings instance and the project itself.

Build Lifecycle

A build is a Gradle execution. Each build starts with instantiation of a Settings and Gradle instance, then of at least one project, which in turn contains tasks, and it can be configured and controlled with properties. Depending on the specific of the build, other Gradle core types are instantiated as well. The lifecycle of a Gradle build consists in an initialization, configuration and an execution phase. Code can be written to react to a build's lifecycle events.

Initialization Phase

The build starts with the initialization phase. Gradle creates a Gradle instance and a Settings instance, then executes the settings script, which updates the state of its Settings delegate. In case of a simple project, Gradle creates the Project instance. For a multi-project build, and depending on which project is executed, Gradle figures out which of the project dependencies need to participate in the build. It creates a project representation for each of the projects, defining the build's project hierarchy. The sub-projects are declared using the "include" or "includeFlat" Settings methods in settings.gradle. Note that at the initialization phase, Project instances are not accessible from the settings script. Project data can be accessed via a ProjectDescriptor interface instead.

Extra properties for Gradle and Settings object instances can be declared at this phase. None of the build scripts is executed in this phase.

Configuration phase. The code declared in build.gradle is executed in order. Tasks are instantiated and configured, by executing their configuration closures. Any configuration code is executed with every build of the project. Gradle constructs a task DAG. The incremental build features determines if any of the tasks in the model are required to run.

Execution phase. Task actions are executed in the correct order, as determined by their dependencies. Task considered up-to-date are skipped.

Convention over Configuration

Subjects

TO DEPLETE

Gradle Concepts TO DEPLETE