---
# System prepended metadata

title: Important Scenarios

---

# Important Scenarios
## Introduction
In order to fully understand the concerns of Gradle's stakeholders, here we provide a few scenarios pertaining to the most important concerns
## Scenario 1: Unproblematic Gradle build
1. Overview: A member of a software development team wants to test their changes on a build. The software system already has defined the projects needed for a build.

2. System state: The source code contains correctly defined gradle source files (build.gradle and settings.gradle) that defines the system to be built. 

3. System environment: There may or may not be an instance of the Gradle Daemon running in the background.

4. External stimulus: The developer runs the build by calling Gradle with the appropriate build command. For most software projects this will be ```gradle build```.

5. Required system response: Gradle recompiles all the source code that the developer has changed and the software system is built in a timely fashion such that minimal developer time is wasted.

## Scenario 2: Applying Plugins to increase Gradle's Functionality
1. Overview: A developer is extending what his/her Gradle build can achieve by adding a Plugin to their build.

2. System state: The plugin has not been applied yet. The build.gradle references the plugin and in what context to apply the plugin in. It also declares where Gradle should look to find the Plugin (if needed).

3. System environment: The plugin that the developer wants to apply is available locally or on a supported repository. The dependencies to the plugin are also available.

4. External stimulus: The developer runs the build task that references the plugin task.

5. Required system response: Gradle retrieves the plugin, applies it to the project, retreives any dependencies, and applies the plugin to the project. The relevant task added by the plugin is executed and the expected behavior is observed.

## Scenario 3: Compile only what changed (Incremental Build)
1. Overview: This scenario demonstrates how Gradle checks if inputs to a task changes so that only what is changed is rerun.

2. System state: The build is being run. Builds on of the same type have already been run in the past on the machine.

3. System environment: N/A

4. Environment changes: The source code was changed in such a way that an input to a task has changed.

5. Required system behavior: Gradle only reruns the tasks that depend on the input that had changed and the tasks that depend on the task that was reran. Non-cachable tasks are always rerun.