image::task-dag-examples.png[]

[[build_lifecycle_events]]
Both plugins and build scripts contribute to the task graph via the <<tutorial_using_tasks.adoc#sec:task_dependencies,task dependency mechanism>> and <<incremental_build.adoc#sec:task_inputs_outputs,annotated inputs/outputs>>.

[[sec:build_phases]]
== Build Phases

A Gradle build has three distinct phases.

image::author-gradle-1.png[]

Gradle runs these phases in order:

                "Declare the task as untracked by using Task.doNotTrackState(). " +
                new DocumentationRegistry().getDocumentationRecommendationFor("information", "incremental_build", "sec:disable-state-tracking")
            )
            failure.assertHasCause("java.nio.file.AccessDeniedException: ${dir}")
        } finally {
            dir.permissions = oldPermissions
        }
    }

[[sec:continuous_build_untracked]]
=== Inputs of untracked tasks
Changes to the inputs of <<incremental_build.adoc#sec:disable-state-tracking,untracked tasks>> or tasks that have no outputs may not trigger a build.

[[sec:continuous_build_project_dir]]
=== Changes to files outside of project directories

`clean__Task__` — task rule::
Removes the <<incremental_build.adoc#sec:task_inputs_outputs,defined outputs>> of a task, e.g. `cleanJar` will delete the JAR file produced by the `jar` task of the Java Plugin.


[[sec:base_plugin_configurations]]
== Dependency management

            this.config = config
            this.message = config.render()
            this.severity = severity
            this.id = id
            this.section = section
            this.defaultDocLink = (id == "incremental_build") && (section == "")
        }

└── subproject-b
    └── build.gradle
----
=====
====

== Avoid overlapping task outputs

Tasks should define inputs and outputs to get the performance benefits of <<incremental_build.adoc#incremental_build,incremental build functionality>>.
When declaring the outputs of a task, make sure that the directory for writing outputs is unique among all the tasks in your project.

[[part:optimizing_build_times]]
== **OPTIMIZING BUILD PERFORMANCE**

include::performance.adoc[leveloffset=+2]
include::gradle_daemon.adoc[leveloffset=+2]
include::file_system_watching.adoc[leveloffset=+2]
include::incremental_build.adoc[leveloffset=+2]
include::configuration_cache.adoc[leveloffset=+2]
include::inspect.adoc[leveloffset=+2]
include::config_gradle.adoc[leveloffset=+2]
include::project_properties.adoc[leveloffset=+2]

You also lose the advantages of Gradle's conventions, many of its plugins, its dependency management, and so on.
You can still enhance the build with <<incremental_build.adoc#incremental_build,incremental build information>>, but it's more effort than would be the case for a normal Gradle build.

 * An idiomatic Gradle build
+
If you want to future proof your build, this is where you want to end up.

====

The above example demonstrates the basic syntax and also highlights two major limitations of using the `copy()` method:

1. The `copy()` method is not <<incremental_build.adoc#incremental_build,incremental>>.
The example's `copyMethod` task will _always_ execute because it has no information about what files make up the task's inputs.
You have to define the task inputs and outputs manually.

`UP-TO-DATE`:: *Task's outputs did not change.*
* Task has outputs and inputs but they have not changed. See <<incremental_build.adoc#incremental_build,Incremental Build>>.
* Task has actions, but the task tells Gradle it did not change its outputs.