anchor.diff:  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]"]
  -====
  -
  
positive.code: * The class analysis is cached in the project directory, so the first build after a clean checkout can be slower. Consider turning off the incremental compiler on your build server.
  
  [[sec:incremental_compilation_known_issues]]
  ==== Known issues
  
  * If a compile task fails due to a compile error, it will do a full compilation again the next time it is invoked.
  * If you are using an annotation processor that reads resources (e.g. a configuration file), you need to declare those resources as an input of the compile task.
  * If a resource file is changed, Gradle will trigger a full recompilation.
  
  [[sec:incremental_annotation_processing]]
  === Incremental annotation processing
  
  Starting with Gradle 4.7, the incremental compiler also supports incremental annotation processing.
  All annotation processors need to opt in to this feature, otherwise they will trigger a full recompilation.
  
negative.code: As a user you can see which annotation processors are triggering full recompilations in the `--info` log.
  Incremental annotation processing will be deactivated if a custom `executable` or `javaHome` is configured on the compile task.
  
  === Making an annotation processor incremental
  
  Please first have a look at <<#sec:incremental_compile,incremental Java compilation>>, as incremental annotation processing builds on top of it.
  
  