All Implemented Interfaces and Traits:

CommandLineArgumentProvider

@CompileStatic
class GrailsProjectOutputDirProvider
extends java.lang.Object
implements CommandLineArgumentProvider

Provides a system property naming one of the build's directories, relative to the project directory, to forked JVM tasks: grails.project.class.dir for the main source set's Groovy classes (BuildSettings.PROJECT_CLASSES_DIR), grails.project.resource.dir for its resources (BuildSettings.PROJECT_RESOURCES_DIR), and grails.project.target.dir for the build directory itself (BuildSettings.PROJECT_TARGET_DIR), where development keeps its restart marker (.grailspid).

In development a changed source file is compiled again into BuildSettings.BUILD_CLASSES_PATH, and a changed message bundle is copied into BuildSettings.BUILD_RESOURCES_PATH, each resolved against the directory of the project that owns the file; BuildSettings.RESOURCES_DIR is where the application reads resources from in development. Without these properties they fall back to build/classes/groovy/main and build/resources/main, so an application whose build directory is elsewhere (a second instance of one checkout built with -PbuildDir, say) had each change compiled or copied where it does not load from: the artefact was reloaded from the class it already had, and the old code went on answering.

The path is relative because it is joined to a project directory, and its names are separated by / on every platform, as the fallbacks are, because IOUtils compares the classes path with class locations written as URLs. When the directory has no path relative to the project, such as one on another drive on Windows, no property is passed, the application keeps the fallback, and a warning names both directories and what that property's fallback means (withoutIt).

A build that sets the property on the task itself (systemProperty 'grails.project.class.dir', ...) keeps its value: nothing is passed then. The task's system properties are read when the task runs, so a value set after the plugin is applied counts too.

A directory outside the project gives a path that climbs out of it (../). Joining it, as GrailsApp.recompile, MainClassFinder and the i18n plugin do, resolves correctly; the IOUtils lookups that compare it with a class location find no match and fall back as they did before.

The paths are also joined to the directory of a plugin subproject whose sources development watches, so they assume every project lays out its build directory in the same way relative to itself, as Gradle's -PbuildDir or an allprojects block does. A plugin subproject whose build directory is laid out differently from the application's has its changes compiled where it does not load classes from.

All four values are Internal, as for GrailsAppBaseDirProvider: the classes and resources directories are the task's classpath, already tracked there; the build directory itself only says where the application writes its restart marker while it runs, which nothing the task produces depends on; and the task's system properties are its inputs already. The directory is read when the task runs, so a build directory changed after the plugin is applied is the one passed.