---
# System prepended metadata

title: Appendix

---

# Appendix
[Glossary](https://hackmd.io/wlbMQxXaSmuTBk5hLWpKDQ#Glossary)



## Glossary
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. |

### Relationship between Build, Action, and a Task
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.

## Extra Information

### Build Cache

##### Incremental Builds
To improve performance Gradle executes [incremental builds](https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:up_to_date_checks). 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. 


##### Configuration

The configuration phase is part of Gradle's [build lifecycle](https://docs.gradle.org/current/userguide/build_lifecycle.html#build_lifecycle). During this phase, the build scripts are loaded to configure run-time objects as described partially by the [configuration object definition model](https://hackmd.io/pxTuGPrNQi2Am2p5z5U8Jw?both#Configuration-Object-Definition-Model). Much like source code, if the script files were not modified then their corresponding objects can be fetched from previously cached executions. For example, if the settings.gradle file was not modified, then a serialized Settings instance can be fetched from the cache. This improves performance.

##### Cacheable Task
A task is cacheable if its output is both relocatable and reproducible as evidence by the [code](https://github.com/gradle/gradle/blob/master/subprojects/core-api/src/main/java/org/gradle/api/tasks/CacheableTask.java). At run-time tasks which are labelled as *cacheable* may be skipped given that a valid cache entry can be found.
##### Local Cache
Gradle's local cache refers to the cached entites stored on a local (mounted) file system. The cached entities are typically found in a [configurable local directory](https://github.com/gradle/gradle/blob/5e08aaad9dbddfda762904006127f2662af33453/subprojects/core-api/src/main/java/org/gradle/caching/local/DirectoryBuildCache.java#L24).
##### Remote Cache
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](https://github.com/gradle/gradle/blob/master/subprojects/build-cache-http/src/main/java/org/gradle/caching/http/HttpBuildCache.java), which can be configured via the Gradle build scripts.


### Script files
#### build.gradle
##### Configure Project
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'
    }
}
```
##### Add Tasks
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.

#### gradle.properties
##### Setting Project Specific Properties

```org.gradle.project.myproject=myproperty```


## Architectural Style & Software Design Patterns
### Microkernel Architectural Style

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](https://hackmd.io/dGIiC6_sRrqdVqo3gRFUmQ) and [information view](https://hackmd.io/pxTuGPrNQi2Am2p5z5U8Jw). 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. 

### Command Design Pattern

The command design pattern is a software design pattern. A command is an action which may be executed at a later time. Instead of simple method containing detail an action's functionality, commands additionally contain necessary information required for delayed execution, such as the method's (action) 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](https://github.com/gradle/gradle/blob/96a84592d30e211f334679bf5de126f1915d1080/subprojects/core-api/src/main/java/org/gradle/api/tasks/TaskState.java) and a [task execution context](https://github.com/gradle/gradle/blob/05f603bc1d5b89ad7e92dec1c0f27f81871b61be/subprojects/core/src/main/java/org/gradle/api/internal/tasks/TaskExecutionContext.java) (and other things). Tasks have [task properties](https://github.com/gradle/gradle/blob/fd2c0a3d3b7ca52b1d2b6eb17133b33693d11b7b/subprojects/core-api/src/main/java/org/gradle/api/Task.java#L542), which are analogous to input parameters.