Gradle Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(204 intermediate revisions by the same user not shown)
Line 1: Line 1:
=External=
=External=


* API reference https://docs.gradle.org/current/javadoc/index.html
* DSL reference https://docs.gradle.org/current/dsl/
* DSL reference https://docs.gradle.org/current/dsl/


Line 10: Line 11:
=Overview=
=Overview=


Gradle is a general-purpose build tool, which can build pretty much anything its [[#Configuration_Scripts|configuration scripts]] declare. It is primarily used to build Java and Groovy, but it can build other languages as well.
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 [[Gradle Task#Overview|tasks]], in a desired sequence. The sequence in which tasks are executed is determined based on the dependencies declared between tasks. Gradle guarantees that the tasks are executed in the order of their dependencies, and each task is executed only once. This behavior is achieved by building a task [[Graph_Concepts#Directed_Acyclic_Graph|directed acyclic graph]], before any task is executed. Each build runs according to a well defined [[#Build_Lifecycle|build lifecycle]], during which Gradle instantiates a complex domain model of the project in memory: a [[Org.gradle.api.invocation.Gradle|Gradle instance]], a [[Gradle_Settings|Settings instance]] and the [[Gradle_Project|project]] itself. The domain model at runtime and ultimately the task dependency graph is configured by a set of [[#Standard_Build_Configuration_Scripts|build configuration scripts]].


=<span id='Build_Lifecycle_and_Gradle_Objects'></span>Build Lifecycle=
=<span id='Build'></span>Build Lifecycle=
{{External|https://docs.gradle.org/current/userguide/build_lifecycle.html}}


Each build run results in the instantiation of one or more of these ''core Gradle types'': the build starts with instantiation of a [[#Settings|Settings]] and a [[Gradle_Object_Instance#Overview|Gradle]] instance, then of one or more [[Gradle_Project_and_Build_Script#Overview|Projects]]. A Gradle execution results in instantiation and execution of [[#Task|task]]. Depending on the actual configuration of the build, many others objects are instantiated and used. All Gradle [https://docs.gradle.org/current/dsl/#N100CA core types are listed here].
A build is a Gradle execution. Each build starts with instantiation of a [[Gradle_Settings|Settings]] and [[Org.gradle.api.invocation.Gradle|Gradle]] instance, then of at least one [[Gradle Project#Overview|project]], which in turn contains [[Gradle Task#Overview|tasks]], and it can be configured and controlled with [[Gradle Properties - Runtime and Project Configuration#Overview|properties]]. Depending on the specific of the build, other [https://docs.gradle.org/current/dsl/#N100CA Gradle core types] are instantiated as well. The lifecycle of a Gradle build consists in an [[#Build_Initialization_Phase|initialization]], [[#Build_Configuration_Phase|configuration]] and an [[#Build_Execution_Phase|execution phase]]. Code can be written to [[Gradle Reacting to Build Lifecycle Events|react to a build's lifecycle events]].


The lifecycle of a Gradle build consists in an [[#Build_Initialization_Phase|initialization]], [[#Build_Configuration_Phase|configuration]] and an [[#Build_Execution_Phase|execution phase]]. Code can be written to react to a build's lifecycle events: {{Internal|Gradle_Project_and_Build_Script#Reacting_to_Build_Lifecycle_Events|Reacting to a Build Lifecycle Events}}
====<span id='Initialization'></span><span id='Build_Initialization'></span>Initialization Phase====
The build starts with the initialization phase. The goal of initialization phase is to create the [[Gradle_Project|Project]] instances that are going to take part in the build.


====<span id='Build_Initialization_Phase'></span>Initialization====
To achieve that, Gradle creates a [[Org.gradle.api.invocation.Gradle|Gradle]] instance and a [[Gradle_Settings|Settings]] instance, then executes the [[settings.gradle|settings script]]. The content of [[settings.gradle|settings script]] 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 specified in the Settings object, plus the root project, 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, and some of it mutated, via a [[Gradle_ProjectDescriptor|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.
The build lifecycle starts with the initialization phase, when Gradle creates a [[Gradle_Settings_Script_and_Settings_Instance#Overview|Settings]] instance, then executes the [[Gradle_Settings_Script_and_Settings_Instance#Overview|settings script]], which updates the state of its [[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_and_Build_Script#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='Project_Instance_Creation'></span>The corresponding [[Gradle_Project_and_Build_Script#Overview|Project]] instances are created and arranged in the corresponding project hierarchy. 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.
====<span id='Build_Configuration_Phase'></span><span id='Configuration'></span>Configuration Phase====


====<span id='Build_Configuration_Phase'></span>Configuration====
The goal of configuration phase is to configure all Project instances that are part of the build.
The build continues with a configuration phase. Gradle executes the [[Gradle_Project_and_Build_Script#Overview|build.gradle]] configuration script against the [[Gradle_Project_and_Build_Script#Root_Project|root project]] instance and its [[Gradle_Project_and_Build_Script#Sub-Project|sub-projects]]. As part of the configuration sequence, [[Gradle_Plugins#Plugin_Initialization|plugins]] declared with apply(...) in the build scripts are downloaded and initialized in their corresponding [[Gradle_Settings_Script_and_Settings_Instance#Overview|Project]] instances. Note that prior to Gradle 1.4, all projects that are part of the hierarchy are configured. Gradle 1.4 and newer introduces [[Gradle_Configuration_on_Demand#Overview|configuration on demand]], that results in configuring only relevant projects.


====<span id='Build_Execution_Phase'></span>Execution====
The code declared in [[build.gradle]] is executed in order in which it was declared in the file, against the [[Gradle_Project|root project]] instance and its sub-projects. <font color=darkgray>The order in which Project instances is configured is determined ? </font>The build script dependencies are downloaded. The [[Gradle Plugin Concepts|plugins]] declared in the build scripts are downloaded and initialized in their corresponding Project instances. According to the [[Gradle_Configuration_on_Demand#Overview|configuration on demand]] principle, only relevant projects are configured. Tasks are [[Gradle_Task#Task_Lifecycle|instantiated and configured]], by executing their [[Gradle_Task#Task_Configuration_Closure|configuration closures]], also in the order in which they are declared in build.gradle.  Any configuration code is executed with every build of the project. Gradle constructs a task DAG.  
The execution phase requires that one or more [[#Task|tasks]] is specified on command line. Gradle computes a task Directed Acyclic Graph of to be executed in order to fulfill the specified tasks, and then [[Gradle_Task#Task_Execution_Order|executes them]] honoring inter-task dependencies and insuring the fact that a task is executed only once.


=Configuration Scripts=
<font color=darkgray>TODO:
* The [[Gradle_Task#Incremental_Builds|incremental build]] features determines if any of the tasks in the model are required to run.
* How to ensure that configuration code corresponding to a task that is introduced by a plugin, and not declared in build.gradle, is also run?
</font>


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_Script|build scripts]], a [[#Settings_Script|settings script]] and an [[#Init_Script|init script]].
====<span id='Build_Execution_Phase'></span><span id='Execution'></span>Execution Phase====


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.
The goal of this phase is to determine the subset of [[#Gradle_Task|tasks]] to be executed, and execute them. The subset is determined by the task name arguments passed to the gradle command. Task actions are [[Gradle_Task#Task_Lifecycle|executed]] in the correct order, as determined by their [[Gradle_Task_Dependencies_and_Ordering#Overview|dependencies]]. Execution phase is when the [[Gradle_Incremental_Builds#Up-to-Date_Check|up-to-date checks]] for the task that have relevant inputs and outputs are preformed. Task considered up-to-date are skipped and a a task is executed only once.


::[[Image:Gradle_Configuration_Scripts.png]]
=Configuration Scripts=
 
==Syntax==
A configuration script may contain [[#Statement|statements]], [[#Script_Block|script blocks]], and any elements allowed in a Groovy script, such as method and class definitions.
The configuration scripts are written in the Gradle build language, which is a Groovy extension DSL. Each configuration script (<code>[[init.gradle]]</code>, <code>[[settings.gradle]]</code> and <code>[[build.gradle]]</code>) implement the [https://docs.gradle.org/current/dsl/org.gradle.api.Script.html Script] interface. The script contain [[#Statements|statements]], [[#Script_Blocks|script blocks]] and any elements allowed in a Groovy script, such as method and class definitions. The script elements are executed in the order in which they are declared in the script and they apply to the script's delegate object. Though syntax is similar for all three scripts, specific blocks must make sense with the delegate object.  


<span id='Statement'></span>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:
A common convention applied in configuration scripts is that setting a property replaces the value (ex: <code>srcDirs = ['src']</code>), while the corresponding method appends values (ex: <code>srcDir 'src2'</code>).


===<span id='Statement'></span>Statements===
A statement may be a method call, property assignment and local variable definition.
<syntaxhighlight lang='groovy'>
<syntaxhighlight lang='groovy'>
println 'I am here'
println 'this will be sent to stdout'
</syntaxhighlight>
</syntaxhighlight>
 
If the script's 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:
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:
 
<syntaxhighlight lang='java'>
<syntaxhighlight lang='java'>
public interface Settings ... {
public interface Settings ... {
Line 52: Line 56:
}
}
</syntaxhighlight>
</syntaxhighlight>
can be accessed from the corresponding [[settings.gradle]] script with <tt>rootProject</tt>.


can be accessed from the corresponding settings.gradle script with <tt>rootProject</tt>.
===<span id='Script_Block'></span>Script Blocks===
 
A script block is a special case of an executable [[#Statement|statement]], consisting in a method invocation on a closure. Executing the script block results in modification of the associated delegate object, as specified in the closure. This is said to delegate the closure against the target object, or e executed the closure in scope of the class of the target instance. <tt>it</tt> is the default parameter passed to all Groovy closures. A build configuration that does not declare any [[Gradle_Plugin_Concepts|plugin]] has a set of standard script blocks. Plugins may, and usually do, add new script blocks.
<span id='Script_Block'></span>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, <tt>it</tt> is the default parameter passed to the closure. A build configuration that does not declare any [[#Plugin|plugin]] has a set of standard script blocks. Plugins may, and usually do, add new script blocks.
 
Each configuration script implements the [https://docs.gradle.org/current/dsl/org.gradle.api.Script.html Script] interface, which exposes a number of useful methods and properties.
 
==<span id='Settings_Script'></span><span id='Settings'></span>Settings Script and Setting Instance==
 
{{Internal|Gradle_Settings_Script_and_Settings_Instance#Overview|Settings Script and Settings Instance}}
 
==<span id='Build_Script'></span><span id='Build'></span>Build Script and Project Instance==
 
{{Internal|Gradle_Project_and_Build_Script#Overview|Build Script and Project Instance}}
 
==Init Script==
 
{{Internal|Gradle_Init_Script#Overview|Init Script}}
 
=<span id='Artifact_Publishing'></span>Artifacts and Artifact Publishing=
 
A Gradle project produces <span id='Artifact'></span>'''artifacts''', which are the files the project provides to the outside world. An artifact may be built locally by a plugin such as the [[Gradle_Application_Plugin#Overview|Application plugin]], which in turn delegates the artifact building part to [[Gradle_Distribution_Plugin#Overview|Distribution plugin]]. This creates the artifact locally, in the project build areal. However, in most cases, we want these artifacts to be pushed to external repositories, as described here: {{Internal|Gradle Artifact Publishing Concepts#Overview|Gradle Artifact Publishing Concepts}}
 
=<span id='Project'></span>Projects and Multi-Project Builds=
 
A Project is the main API to use to interact with Gradle. All top level statements within a [[Gradle_Project_and_Build_Script#Overview|build script]] are delegated to the corresponding [[Gradle_Project_and_Build_Script#Overview|Project]] instance. [[Gradle_Multi-Project_Builds#Overview|Multi-project builds]] consist of multiple Project instances.
 
{{Internal|Gradle_Project_and_Build_Script#Overview|Build Script and Project Instance}}
 
{{Internal|Gradle_Multi-Project_Builds#Overview|Multi-Project Builds}}
 
=The Gradle Object Instance=
 
{{Internal|Gradle_Object_Instance#Overview|The Gradle Object Instance}}
 
=Task=
A Task represents a single atomic piece of work for a build. A build consists in executing a sequence of tasks in succession, after the task have been arranged in a directed acrylic graph. Understanding how the directed acyclic graph is built and how tasks are scheduled for execution is key to understanding how gradle works. These concepts are explained here:
 
{{Internal|Gradle_Task#Overview|Task}}
 
=Variables and Properties=
 
{{Internal|Gradle Variables and Properties#Overview|Gradle Variables and Properties}}
 
=Module=
 
A '''module''' is a piece of software that evolves over time. Every module has a name, and each release of a module is identified by a [[#Module_Version|module version]]. Modules can be hosted in [[Gradle_Repositories#Overview|repositories]]. Modules usually are described by <span id='Module_Metadata'></span>'''module metadata''', which is information associate with a module. Metadata includes [[Maven_Concepts#Maven_Coordinates|coordinates]] for locating the module in a repository ([[Maven_Concepts#Group_ID|group ID]], [[Maven_Concepts#Artifact_ID|artifact name]] and [[#Module_Version|version]]), information about the module's [[#Transitive_Dependency|transitive dependencies]], authors, etc. In Maven, the metadata file is called [[Maven_pom.xml#Overview|POM]].
 
A <span id='Module_Version'></span>'''module version''' is a label that designates a distinct set of changes released as a unit. The most widely-used versioning strategy is [[Software_Development#Semantic_Versioning|semantic versioning]].
 
=<span id='Dependency'></span><span id='Configurations'></span><span id='Configuration'></span>Dependencies and Dependency Configurations=
 
{{Note|Configuration, in this context, does not refer to a configuration file, as in a settings configuration or a build configuration. It refers to named set of dependencies or artifacts, and it can probably thought of as being a concept similar to a Maven [[Maven_Concepts_-_Dependencies#Dependency_Scope|scope]].}}
 
{{Internal|Gradle_Dependencies_and_Dependency_Configurations#Overview|Gradle Dependencies and Dependency Configurations}}
 
=Repository=
 
{{Internal|Gradle Repositories|Gradle Repositories}}
 
=<span id='Plugin'></span>Plugins=
 
{{Internal|Gradle Plugins|Gradle Plugins}}
 
=<span id='Extension'></span>Extensions=
 
A Project implements [https://docs.gradle.org/current/dsl/org.gradle.api.plugins.ExtensionAware.html ExtensionAware]. Some plugins create extensions. For example, [[Gradle_Maven_Plugin#Overview|maven-plugin]] creates a "[[Gradle_Maven_Publish_Plugin#Mechanics|publishing]]" extension.
 
=<span id='Component'></span>Software Component=
 
A software components may be added by a [[#Plugin|plugin]]. For example the [[Gradle_Java_Plugin#Overview|Java plugin]] adds a "java" component, accessible via components.java. The artifact associated with the Java component is the generated JAR file, and the dependencies are those of the [[Gradle_Java_Plugin#runtime|runtime]] configurations. The [[Gradle_War_Plugin|War plugin]] adds a "web" software component whose artifact is the generated WAR file, with no dependencies.
 
The available components can be displayed with:
 
<syntaxhighlight lang='groovy'>
task util {
 
    components.each { println it.name }
}
</syntaxhighlight>
 
=The Gradle Wrapper=
 
{{External|https://docs.gradle.org/current/userguide/gradle_wrapper.html}}
 
Gradle Wrapper is the recommended way to execute a Gradle build. The Wrapper is a script that invokes a declared version of Gradle, downloading it beforehand if necessary.
 
./gradlew ...
 
The wrapper caches the appropriate Gradle runtime under $USER_HOME/.gradle/wrapper/dists/. Using the wrapper effectively locks a specific Gradle version to the project. Per-project graddle wrapper infrastructure can be created with [[Gradle_Operations#Start_a_Project|gradle init]].
 
One of the advantages of using the Gradle wrapper is that other people that attempt to build the project do not have to have Gradle installed on their system, everything Gradle needs to run comes with the wrapper.
 
=The Gradle Daemon=
 
{{External|https://docs.gradle.org/current/userguide/gradle_daemon.html}}
 
Configured with "org.gradle.daemon" and "org.gradle.daemon.idletimeout" [[Gradle_Variables_and_Properties#Gradle_Properties|Gradle property]]. On by default.
 
=Build Caching=
 
{{Internal|Gradle Build Caching#Overview|Build Caching}}


=Configuration on Demand=
==<span id='Available Scripts'></span>Standard Build Configuration Scripts==
* <span id='init.gradle'></span><code>[[init.gradle]]</code>
* <code>[[settings.gradle]]</code>
* <code>[[build.gradle]]</code>
[[File: Gradle_Configuration_Scripts.png]]


{{Internal|Gradle Configuration on Demand#Overview|Configuration on Demand}}
=Convention over Configuration=
Gradle pre-configures projects with sensible default configurations, called conventions. For example, production source code sits in src/main/java while test code sits in src/test/java. These conventions are borrowed from Apache Maven. However, conventions can be overridden through configuration if there is a good reason.


=Gradle Programming=
=Subjects=
* <span id='Project'></span><span id='Gradle_Project'></span>[[Gradle Project|Project]], [[Gradle_Multi-Project_Builds#Overview|Multi-Project Builds]], [[Gradle Reacting to Build Lifecycle Events|Reacting to Build Lifecycle Events]], [[Gradle_ProjectDescriptor|ProjectDescriptor]]
* [[Gradle Dependencies and Dependency Configurations|Gradle Dependencies and Dependency Configurations]]
* <span id='Gradle_Repositories'></span>[[Gradle Repositories]]
* <span id='Task'></span><span id='Gradle_Task'></span>[[Gradle Task|Task]], [[Gradle_Task#Standard_Lifecycle_Tasks|Standard Lifecycle Tasks]], [[Extending Gradle with a Custom Enhanced Task|Extending Gradle with a Custom Enhanced Task]], <span id='Incremental_Builds'></span>[[Gradle Incremental Builds#Overview|Incremental Builds]], <span id='Build_Cache'></span>[[Gradle Build Cache|Build Cache]]
* <span id='Properties'></span><span id='Gradle_Properties'></span>[[Gradle Properties - Runtime and Project Configuration|Gradle Properties - Runtime and Project Configuration]]
* <span id='Gradle_Instance'></span><span id='Gradle'></span>[[org.gradle.api.invocation.Gradle|Gradle Instance]], <span id='Gradle_Settings'></span><span id='Settings'></span>[[Gradle Settings|Settings Instance]]
* <span id='Logging'></span><span id='Gradle_Logging'></span>[[Gradle Logging|Logging]]
* <span id='Plugin'></span><span id='Gradle_Plugin'></span>[[Gradle Plugin Concepts|Plugins]], [[Gradle Java Plugin|Java Plugin]], [[Gradle Java Library Plugin|Java Library Plugin]]
* <span id='Extending_Gradle'></span>[[Extending Gradle|Extending Gradle]]
* <span id='Gradle_File_Resolution'></span>[[Gradle File Resolution]]
* <span id='Configuration_on_Demand'>[[Gradle Configuration on Demand|Configuration on Demand]]
* [[Gradle Daemon]]
* [[Gradle Wrapper]]
* [[Gradle Files Layout]]
* [[Gradle Software Components]]
* [[Gradle Process Model]]
* [[Gradle Extensions]]


{{Internal|Gradle_Programming#Overview|Gradle Programming}}
=TO DEPLETE=
{{Internal|Gradle Concepts TO DEPLETE|Gradle Concepts TO DEPLETE}}
{{Internal|Gradle Programming TODEPLETE|Gradle Programming TO DEPLETE}}

Latest revision as of 01:38, 19 January 2023

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 a desired sequence. The sequence in which tasks are executed is determined based on the dependencies declared between tasks. Gradle guarantees that the tasks are executed in the order of their dependencies, and each task is executed only once. This behavior is achieved by building a task directed acyclic graph, before any task is executed. 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. The domain model at runtime and ultimately the task dependency graph is configured by a set of build configuration scripts.

Build Lifecycle

https://docs.gradle.org/current/userguide/build_lifecycle.html

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. The goal of initialization phase is to create the Project instances that are going to take part in the build.

To achieve that, Gradle creates a Gradle instance and a Settings instance, then executes the settings script. The content of settings script 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 specified in the Settings object, plus the root project, 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, and some of it mutated, 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 goal of configuration phase is to configure all Project instances that are part of the build.

The code declared in build.gradle is executed in order in which it was declared in the file, against the root project instance and its sub-projects. The order in which Project instances is configured is determined ? The build script dependencies are downloaded. The plugins declared in the build scripts are downloaded and initialized in their corresponding Project instances. According to the configuration on demand principle, only relevant projects are configured. Tasks are instantiated and configured, by executing their configuration closures, also in the order in which they are declared in build.gradle. Any configuration code is executed with every build of the project. Gradle constructs a task DAG.

TODO:

  • The incremental build features determines if any of the tasks in the model are required to run.
  • How to ensure that configuration code corresponding to a task that is introduced by a plugin, and not declared in build.gradle, is also run?

Execution Phase

The goal of this phase is to determine the subset of tasks to be executed, and execute them. The subset is determined by the task name arguments passed to the gradle command. Task actions are executed in the correct order, as determined by their dependencies. Execution phase is when the up-to-date checks for the task that have relevant inputs and outputs are preformed. Task considered up-to-date are skipped and a a task is executed only once.

Configuration Scripts

Syntax

The configuration scripts are written in the Gradle build language, which is a Groovy extension DSL. Each configuration script (init.gradle, settings.gradle and build.gradle) implement the Script interface. The script contain statements, script blocks and any elements allowed in a Groovy script, such as method and class definitions. The script elements are executed in the order in which they are declared in the script and they apply to the script's delegate object. Though syntax is similar for all three scripts, specific blocks must make sense with the delegate object.

A common convention applied in configuration scripts is that setting a property replaces the value (ex: srcDirs = ['src']), while the corresponding method appends values (ex: srcDir 'src2').

Statements

A statement may be a method call, property assignment and local variable definition.

println 'this will be sent to stdout'

If the script's 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.

Script Blocks

A script block is a special case of an executable statement, consisting in a method invocation on a closure. Executing the script block results in modification of the associated delegate object, as specified in the closure. This is said to delegate the closure against the target object, or e executed the closure in scope of the class of the target instance. it is the default parameter passed to all Groovy closures. 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.

Standard Build Configuration Scripts

Gradle Configuration Scripts.png

Convention over Configuration

Gradle pre-configures projects with sensible default configurations, called conventions. For example, production source code sits in src/main/java while test code sits in src/test/java. These conventions are borrowed from Apache Maven. However, conventions can be overridden through configuration if there is a good reason.

Subjects

TO DEPLETE

Gradle Concepts TO DEPLETE
Gradle Programming TO DEPLETE