anchor.diff:  
   This allows us to link:https://github.com/gradle/gradle/blob/7b047c7cbb4932743243a76123f5347be6d07856/subprojects/jacoco/src/main/java/org/gradle/testing/jacoco/plugins/JacocoPluginExtension.java#L138-L157[model the JaCoCo Java agent], thus declaring the necessary JVM arguments and providing the inputs and outputs to Gradle:
   
  +====
   [source,java]
   .JacocoAgent.java
   ----
  
positive.code: 
  As an example, let's look at the `Copy` task provided by Gradle. To create a `Copy` task for your build, you can declare in your build script:
  
  === Example: Creating a copy task
  
  [source.multi-language-sample,groovy]
  .build.gradle
  ----
  include::{samplesPath}/userguide/tasks/configureUsingClosure/build.gradle[tag=declare-task]
  ----
  
  This creates a copy task with no default behavior. The task can be configured using its API (see link:{groovyDslPath}/org.gradle.api.tasks.Copy.html[Copy]). The following examples show several different ways to achieve the same configuration.
  
  Just to be clear, realize that the name of this task is “`myCopy`”, but it is of _type_ “`Copy`”. You can have multiple tasks of the same _type_, but with different names. You'll find this gives you a lot of power to implement cross-cutting concerns across all tasks of a particular type.
  
  === Example: Configuring a task - various ways
  
  [source.multi-language-sample,groovy]
  .build.gradle
  ----
  include::{samplesPath}/userguide/tasks/configureUsingVar/build.gradle[]
  ----
  
  This is similar to the way we would configure objects in Java. You have to repeat the context (`myCopy`) in the configuration statement every time. This is a redundancy and not very nice to read.
  
  There is another way of configuring a task. It also preserves the context and it is arguably the most readable. It is usually our favorite.
  
  === Example: Configuring a task - with closure
  
  [source.multi-language-sample,groovy]
  .build.gradle
  ----
  include::{samplesPath}/userguide/tasks/configureUsingClosure/build.gradle[tag=all]
  ----
  
  This works for _any_ task. Line 3 of the example is just a shortcut for the `tasks.getByName()` method. It is important to note that if you pass a closure to the `getByName()` method, this closure is applied to _configure_ the task, not when the task executes.
  
  You can also use a configuration closure when you define a task.
  
  === Example: Defining a task with closure
  
  [source.multi-language-sample,groovy]
  .build.gradle
  ----
  include::{samplesPath}/userguide/tasks/defineAndConfigure/build.gradle[tag=no-description]
  ----
  
  [TIP]
  .Don't forget about the build phases
  
negative.code: > gradle processTemplates
  include::{samplesPath}/userguide/tasks/incrementalBuild/customTaskClass/customTaskClassWithInputOutputAnnotationsUpToDate.out[]
  ----
  ====
  
  There’s plenty to talk about in this example, so let’s work through each of the input and output properties in turn:
  
  