Gradle warning about @Input Path property


I’ve written a Gradle task which has a property like this:

var directory: Path = defaultDirectory

However, Gradle’s validateTaskProperties task is complaining:

Task property validation finished with warnings:

  • Warning: Task type ‘com.example.plugin.MyTask’: property ‘directory’ has @Input annotation used on property of type java.nio.file.Path.

I could obviously replace @Input with @InputDirectory here, except that the Javadoc for @InputDirectory says the following:

This will cause the task to be considered out-of-date when the directory location or contents have changed. To make the task dependent on the directory location but not the contents, use an Input annotation instead.

i.e. that @Input is perfectly legal for a Path property, and should be used when the task only cares about the location and not about the directory’s contents.

So is there a way of disabling this warning for this particular property please?


Even though @Input should be used for the case where you only care about the location, not the contents, this is almost always not the desired behavior. The warning exists to make sure that you’re completely aware of this behavior.

If you absolutely can’t tolerate a warning that’s making sure you want special behavior, you have the option of not registering the Path as in input. Instead, you can annotate any getter than returns the value you actually care about for UP-TO-DATE checks. This could simply be the directory as a String.

Hi, thanks for the reply.

This particular Path denotes a directory which will contain an installation of a software package, including a subdirectory full of log files. So the directory’s contents will change - that is guaranteed, and we wouldn’t want Gradle to reinstall the package in that case anyway.

Rather than mangle the plugin by treating what is really a Path as a String, could there be some kind of @SuppressWarnings option for this property?

The types that you deal with in your code are totally up to you. There’s no reason you need to mangle anything to map the inputs appropriately. Groovy allows you simply annotate the property, but it is common for there to be multiple getters associated with a property and for the correct getter to be annotated (required in Java), such as:

private Path path;

public Path getPath() {
    return path;

public String getPathName() {
    return path.normalize().toString();

Yes, except that

public String getPathName() {
    return path.normalize().toString();

is a method / property that serves no purpose other than to suppress a warning about documented behaviour. I was hoping to avoid such code, because I’ve noticed that a degree of “cargo culting” tends to grow up about Gradle code.