anchor.diff:  .Java plugin - tasks
   image::javaPluginTasks.png[]
   
  +
  +[[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]"]
  +====
   
   
   [[sec:java_plugin_and_dependency_management]]
  
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: * 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.
  