If you use the `@Input` annotation on a file-based property, Gradle wouldn't consider the file contents, or the directory contents, as inputs, as you might expect.

 * Standard metadata like `module`, `organisation` and `revision`.
 * Other contents of the module descriptor — via link:{groovyDslPath}/org.gradle.api.publish.ivy.IvyPublication.html#org.gradle.api.publish.ivy.IvyPublication:descriptor(org.gradle.api.Action)[IvyPublication.descriptor(org.gradle.api.Action)].

This is especially useful when multiple JDKs are installed:

----
❯ echo %JAVA_HOME%
C:\Program Files\Java\jdk1.7.0_80
----

----
❯ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk-16.jdk/Contents/Home
----

Gradle supports link:https://kotlinlang.org/[Kotlin] and link:https://groovy-lang.org/[Groovy] as the main build languages.

 2. Develop a mechanism to verify that the two builds produce the same artifacts.
+
This is a vitally important step to ensure that your deployments and tests don't break.
Even small changes, such as the contents of a manifest file in a JAR, can cause problems.

     | Is JDK:             true
     | Detected by:        environment variable 'JDK16'

 + Oracle JDK 1.7.0_80
     | Location:           /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre
     | Language Version:   7
     | Vendor:             Oracle
     | Architecture:       x86_64
     | Is JDK:             false
     | Detected by:        MacOS java_home
----

|`@PathSensitive`
|Property is one or more files and only the given part of the file path is important

|`@IgnoreEmptyDirectories`
|Used with `@InputFiles` or `@InputDirectory` to instruct Gradle to track only changes to the contents of directories and not differences in the directories themselves.

|`@NormalizeLineEndings`

=== Running all checks
It is common for _all_ verification tasks, including tests and linting, to be executed using the `check` task:

----
$ gradle check
----

=== Cleaning outputs
You can delete the contents of the build directory using the `clean` task. Doing so will cause pre-computed outputs to be lost, causing significant additional build time for the subsequent task execution:

----
$ gradle clean
----

+
. Develop a mechanism to verify that the two builds produce the same artifacts.
+
This is a vitally important step to ensure that your deployments and tests don't break.
Even small changes, such as the contents of a manifest file in a JAR, can cause problems.

| link:{javadocPath}/org/gradle/api/attributes/LibraryElements.html#LIBRARY_ELEMENTS_ATTRIBUTE[`org.gradle.libraryelements`]
| Indicates the contents of a `org.gradle.category=library` variant
| `LibraryElements` values built from constants defined in link:{javadocPath}/org/gradle/api/attributes/LibraryElements.html[LibraryElements]

The method call returns the Ant data type, which you can use directly in your build script.
In the following example, we create an Ant `path` object, then iterate over the contents of it:

====
include::sample[dir="snippets/ant/useAntType/kotlin",files="build.gradle.kts"]
include::sample[dir="snippets/ant/useAntType/groovy",files="build.gradle"]
====

[[sec:using_custom_ant_tasks]]