If the absolute path represents a tool being used it probably makes sense to track the tool version as an input instead.

For example, if you are using tools in your `Test` task called `integTest` which depend on the contents of the `LANG` variable you should do this:

====

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)].

- new versions of dynamic dependencies
- new versions of changing modules (modules which use the same version string but can have different contents)

--
Refreshing dependencies will cause Gradle to invalidate its listing caches.
However:

- it will perform HTTP HEAD requests on metadata files but _will not re-download them_ if they are identical

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.

It's even more important when considering that the declared order of repositories matter.

[[sec:declaring-repository-filter]]
=== Declaring a repository filter

.Declaring repository contents
====
include::sample[dir="snippets//dependencyManagement/declaringRepositories-filtering/kotlin",files="build.gradle.kts[tags=repository-filter]"]

     | 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
----