Gradle Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 59: Line 59:
The lifecycle of a Gradle build consists in an [[#Build_Initialization_Phase|initialization]], [[#Build_Configuration_Phase|configuration]] and an [[#Build_Execution_Phase|execution phase]].
The lifecycle of a Gradle build consists in an [[#Build_Initialization_Phase|initialization]], [[#Build_Configuration_Phase|configuration]] and an [[#Build_Execution_Phase|execution phase]].


The build lifecycle starts with the <span id='Build_Initialization_Phase'></span>'''initialization''' phase, when Gradle executes the [[Gradle_Settings_Script_and_Settings_Instance#Overview|settings script]], which updates the state of it [[Gradle_Settings_Script_and_Settings_Instance#Overview|Settings delegate]]. In this phase, Gradle determines which projects are going to take part in the build and creates a [[Gradle_Project#Overview|project representation]] for each of the projects. The sub-projects are declared using the "include" or "includeFlat" Settings methods in  [[Gradle_Settings_Script_and_Settings_Instance#Overview|settings.gradle]].
The build lifecycle starts with the <span id='Build_Initialization_Phase'></span>'''initialization''' phase, when Gradle executes the [[Gradle_Settings_Script_and_Settings_Instance#Overview|settings script]], which updates the state of it [[Gradle_Settings_Script_and_Settings_Instance#Overview|Settings delegate]]. In this phase, Gradle determines which projects are going to take part in the build and creates a [[Gradle_Project#Overview|project representation]] for each of the projects, essentially defining the build's project hierarchy. The sub-projects are declared using the "include" or "includeFlat" Settings methods in  [[Gradle_Settings_Script_and_Settings_Instance#Overview|settings.gradle]].


<span id='Build_Configuration_Phase'></span>
<span id='Build_Configuration_Phase'></span>

Revision as of 21:36, 17 May 2018

External

Internal

Overview

Gradle is a general-purpose build tool, which can build pretty much anything its configuration scripts declare. It is primarily used to build Java and Groovy, but it can build other languages as well.

Configuration Scripts

The configuration scripts are written in the Gradle build language, which is a DSL and a Groovy extension. A build is configured by three types of configuration scripts, which together express build requirements and inform the build runtime: build scripts, a settings script and an init script.

Each of those scripts contains executable statements and script blocks, which are a special case of executable statement, consisting in a method invocation on a closure. The statements and script blocks are executed in the order in which they are declared in the script. The logic expressed in a specific script applies to its delegate object. Though syntax is similar for all three scripts, specific blocks must make sense with the delegate object. The corresponding delegate objects for all three types of configuration scripts will be described below.

Gradle Configuration Scripts.png

A configuration script may contain statements, script blocks, and any elements allowed in a Groovy script, such as method and class definitions.

A statement may be a method call, property assignment and local variable definition. One of the simplest possible statements, which will be executed in the order in which is found in the script, is:

println 'I am here'

If the delegate object has an accessor that follows Java Beans conventions, then the result of the accessor invocation can be obtained simply specifying the corresponding variable name. For example, the root project instance returned by:

public interface Settings ... {
    ProjectDescriptor getRootProject();
}

can be accessed from the corresponding settings.gradle script with rootProject.

A script block is method call that takes a configuration closure as an argument. Executing the script block results in modification of the associated delegate object, based on the content of the closure. Equivalent terminology, often used in documentation, is to delegate the closure against the target object. This means that the closure will be executed in scope of the class of the target instance. For all Groovy closures, it is the default parameter passed to the closure. A build configuration that does not declare any plugin has a set of standard script blocks. Plugins may, and usually do, add new script blocks.

Each configuration script implements the Script interface, which exposes a number of useful methods and properties.

Settings Script and Setting Instance

Settings Script and Settings Instance

Build Script

Build Script

Init Script

Init Script

Build Lifecycle and Gradle Objects

Each build run results in the instantiation of one or more of these core Gradle types. The build starts with instantiation of a Settings and a Gradle instance, then of one or more Projects. A Gradle execution results in instantiation and execution of task. Depending on the actual configuration of the build, many others objects are instantiated and used. All Gradle core types are listed here.

The lifecycle of a Gradle build consists in an initialization, configuration and an execution phase.

The build lifecycle starts with the initialization phase, when Gradle executes the settings script, which updates the state of it Settings delegate. In this phase, Gradle determines which projects are going to take part in the build and creates a project representation for each of the projects, essentially defining the build's project hierarchy. The sub-projects are declared using the "include" or "includeFlat" Settings methods in settings.gradle.



Introduce essential plugins.

Gradle

Gradle

Project

A Project is the main API to use to interact with Gradle. All top level statements within a build script are delegated to the corresponding Project instance.

Project

Task

A Task represents a single atomic piece of work for a build.

Task

Fit Containers in.

Extensions, as in publishing extension.

Plugins

Most of Gradle's power comes from external plugins.

  • Java plugin.
  • Maven publishing plugin.