List of terms used in this AD.
Name | Definition |
---|---|
Build | Highest level execution of a Gradle execution. A build starts and ends with the command line call of Gradle. |
Task | Represents a "unit of work". Contains a list of Actions. A Task keeps track of dependencies. Can be marked as cacheable |
Action | A Runnable piece of code |
Artifact | An artifact of a software component that may be requested in the result of an artifact query. |
A build is composed of one or more Projects. These projects have one or more Tasks within them. Each Task is composed of a list of Actions to be executed.
To improve performance Gradle executes incremental builds. An incremental build is one which only recompiles the necessary source files. A source file which has not been modified need not be recompiled. To enable this, Gradle uses the cached output of build related Tasks.
The configuration phase is part of Gradle's build lifecycle.
Much like source code for incremental builds, if the configuration script files were not modified, their corresponding configuration objects can be fetched from previously cached executions rather than loaded from the script files. For example, if the settings.gradle file was not modified, then a serialized Settings instance can be fetched from the cache store. This improves performance.
A task is cacheable if its output is both relocatable and reproducible as evidenced by the code. At run-time tasks which are labelled as cacheable may be skipped provided that a valid entry can be found and fetched from the cache.
Gradle's local cache refers to the cached entites stored on a local (mounted) file system. The cached entities (files) are typically found in a local directory.
Gradle enables cached entities to be accessed remotely. This allows developers to share cache, which may significantly increase performance when building large projects that involve multiple developers. One way to use remote cache would be through an HTTP remote cache, which can be configured via the Gradle build scripts.
Projects can be configured under the buildscript closure in the build.gradle file. The following is an example of how an ArtifactRepository and project dependencies would be appear in the file.
buildscript {
repositories {
maven{url("https://plugins.gradle.org/)}
}
dependencies {
classpath group: 'myclasspath'
}
}
Tasks may be added to the associated project via the task registry. Adding a task to a project is simple, the following code snippet shows how to add an action for a task 'mytask' in a project's build.gradle file.
tasks.register('mytask'){
doFirst{
code
}
}
The action would be executed at the beginning of the task's action list as per the doFirst directive. We can chain actions to create complex behavior as shown in the code snippet below.
tasks.register('mytask'){
doFirst{
codeA
}
}
tasks.register('mytask'){
doFirst{
codeB
}
}
The task will execution will simply be the execution of codeB followed by the execution of codeA.
org.gradle.project.myproject=myproperty
The Microkernel pattern (194) [POSA1] applies to software systems that must adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.
Gradle's provides a core (microkernel) described in the functional view and information view. The core mostly deals with how Gradle is configured and how tasks are executed. The specific tasks being executed usually stem from plug-ins which would be the "extended functionality and customer-specific parts" described in the above paragraph.
The command design pattern is a software design pattern. A command is an action which may be executed at a later time. On top of an action to be executed (e.g. a method call), commands additionally contain necessary information required for delayed execution, such as a method's (action) input parameters. Commands are usually executed via an invoker, which may keep track of previously executed tasks and provide extra features such as an undo/redo functionality.
Gradle tasks are derived from the command design pattern. Tasks are simply a linked-list of actions, which would represent a composite command. They are derived and not a direct application of the command design pattern. Tasks enhances the standard pattern by associating a task with a task state and a task execution context (and other things). Tasks have task properties, which are analogous to input parameters.