It is best practice to
avoid
hardcoded paths in build scripts.
In addition to avoiding hardcoded paths, Gradle encourages laziness in its build scripts.
This means that tasks and operations should be deferred until they are actually needed rather than executed eagerly.
Many examples in this chapter use hard-coded paths as string literals.
This makes them easy to understand, but it is not good practice.
The problem is that paths often change, and the more places you need to change them, the more likely you will miss one and break the build.
Where possible, you should use tasks, task properties, and
project properties
? in that order of preference ? to configure file paths.
For example, if you create a task that packages the compiled classes of a Java application, you should use an implementation similar to this:
build.gradle.kts
val archivesDirPath = layout.buildDirectory.dir("archives")
tasks.register<Zip>("packageClasses") {
archiveAppendix = "classes"
destinationDirectory = archivesDirPath
from(tasks.compileJava)
}
build.gradle
def archivesDirPath = layout.buildDirectory.dir('archives')
tasks.register('packageClasses', Zip) {
archiveAppendix = "classes"
destinationDirectory = archivesDirPath
from compileJava
}
The
compileJava
task is the source of the files to package, and the project property
archivesDirPath
stores the location of the archives, as we are likely to use it elsewhere in the build.
Using a task directly as an argument like this relies on it having
defined outputs
, so it won’t always be possible.
This example could be further improved by relying on the Java plugin’s convention for
destinationDirectory
rather than overriding it, but it does demonstrate the use of project properties.