anchor.diff:  When a source file is recompiled, Gradle will recompile all files generated from it.
   When a source file is deleted, the files generated from it are deleted.
   
  -==== "Aggregating" annotation processors
  +=== "Aggregating" annotation processors
   
   These can aggregate several source files into one ore more output files or validation messages.
   For instance, a `ServiceRegistryProcessor` could create a single `ServiceRegistry` with one method for each type annotated with `@Service`
  
positive.code: include::sample[dir="java/apt/groovy", files="build.gradle[tags=annotation-processing]"]
  include::sample[dir="java/apt/kotlin", files="build.gradle.kts[tags=annotation-processing]"]
  ====
  
  [[sec:java_test]]
  == Test
  
  The `test` task is an instance of link:{groovyDslPath}/org.gradle.api.tasks.testing.Test.html[Test]. It automatically detects and executes all unit tests in the `test` source set. It also generates a report once test execution is complete. JUnit and TestNG are both supported. Have a look at link:{groovyDslPath}/org.gradle.api.tasks.testing.Test.html[Test] for the complete API.
  
  See the <<java_testing.adoc#java_testing,Testing in Java & JVM projects>> chapter for more details.
  
  
  [[sec:jar]]
  == Jar
  
  The `jar` task creates a JAR file containing the class files and resources of the project. The JAR file is declared as an artifact in the `archives` dependency configuration. This means that the JAR is available in the classpath of a dependent project. If you upload your project into a repository, this JAR is declared as part of the dependency descriptor. You can learn more about how to work with archives in <<working_with_files.adoc#sec:archives,Archive creation in depth>> and artifact configurations in <<artifact_management.adoc#artifact_management,Legacy Publishing>>.
  
  
  [[sub:manifest]]
  === Manifest
  
  Each jar or war object has a `manifest` property with a separate instance of link:{javadocPath}/org/gradle/api/java/archives/Manifest.html[Manifest]. When the archive is generated, a corresponding `MANIFEST.MF` file is written into the archive.
  
  .Customization of MANIFEST.MF
  ====
  include::sample[dir="userguide/tutorial/manifest/groovy",files="build.gradle[tags=add-to-manifest]"]
  include::sample[dir="userguide/tutorial/manifest/kotlin",files="build.gradle.kts[tags=add-to-manifest]"]
  ====
  
  You can create stand-alone instances of a `Manifest`. You can use that for example, to share manifest information between jars.
  
  .Creating a manifest object.
  ====
  include::sample[dir="userguide/tutorial/manifest/groovy",files="build.gradle[tags=custom-manifest]"]
  include::sample[dir="userguide/tutorial/manifest/kotlin",files="build.gradle.kts[tags=custom-manifest]"]
  ====
  
  You can merge other manifests into any `Manifest` object. The other manifests might be either described by a file path or, like in the example above, by a reference to another `Manifest` object.
  
  .Separate MANIFEST.MF for a particular archive
  ====
  include::sample[dir="userguide/tutorial/manifest/groovy",files="build.gradle[tags=merge]"]
  include::sample[dir="userguide/tutorial/manifest/kotlin",files="build.gradle.kts[tags=merge]"]
  ====
  
  Manifests are merged in the order they are declared by the `from` statement. If the base manifest and the merged manifest both define values for the same key, the merged manifest wins by default. You can fully customize the merge behavior by adding `eachEntry` actions in which you have access to a link:{javadocPath}/org/gradle/api/java/archives/ManifestMergeDetails.html[ManifestMergeDetails] instance for each entry of the resulting manifest. The merge is not immediately triggered by the from statement. It is done lazily, either when generating the jar, or by calling `writeTo` or `effectiveManifest`
  
  You can easily write a manifest to disk.
  
  .Saving a MANIFEST.MF to disk
  ====
  include::sample[dir="userguide/tutorial/manifest/groovy",files="build.gradle[tags=write]"]
  include::sample[dir="userguide/tutorial/manifest/kotlin",files="build.gradle.kts[tags=write]"]
  ====
  
  
negative.code: * If they use link:{javaApi}/javax/annotation/processing/Filer.html#createResource(javax.tools.JavaFileManager.Location,java.lang.CharSequence,java.lang.CharSequence,javax.lang.model.element.Element++...++)[Filer#createResource], Gradle will recompile all source files.
      See https://github.com/gradle/gradle/issues/4702[gradle/issues/4702]
  
  === "Isolating" annotation processors
  
  The fastest category, these look at each annotated element in isolation, creating generated files or validation messages for it.
  For instance an `EntityProcessor` could create a `<TypeName>Repository` for each type annotated  with `@Entity`.
  