Why no @InputDirectories annotation?

Help/Discuss
1

There is @InputFile, @InputFiles, @InputDirectory.
There is @OutputFile, @OutputFiles, @OutputDirectory, and @OutputDirectories.

Why no @InputDirectories ? I have an include path for a preprocessor, which is a List<? extends File>. How should I annotate that?

Also, documentation for these annotations is a little thin on the ground regarding what types each may annotate. A File? Something which may be passed to project.file()?

As ever, I humbly prostrate myself before your collective wizardry in the hope of eventually attaining enlightenment.

Thank you.

1 Like
2

You could use @InputFiles to accomplish the same thing. The value can be anything that can be passed to Project.files(). In this case if your input was a bunch of different directories, you could construct this as a collection of FileTree.

3

I don’t entirely follow the FileTree note.

  1. If I have a @InputFiles List<File> includePath; which contains only /usr/include and /usr/local/include then Gradle will DTRT with respect to files within those directories?
  2. Who has to call FileTree? Me, before setting the List? Gradle will call it automatically if file.isDirectory() Me, when consuming the eventual object in my task? My preprocessor only requires the list of roots, so as the plugin is now, I never have a need to call fileTree().
4

Making this non-hypothetical, here is the code:

As a separate question, it’s not clear how to call getters in the Java API in VelocityTask such that the convention is honoured?

5

In this case what I would probably do something like this.

@Input
List<File> includeDirs = new ArrayList<>();

@InputFiles
private getIncludedFiles() {
    FileCollection files = getProject().files();
    for (File f : includeDirs) {
        files = files.plus(getProject().fileTree(f));
    }

    return files;
}

The second method is really just so incremental build support will kick in if the contents of any of those directories change. To do this we specify as an input all the files in all of the directories specified by includeDirs.

As for your second question, you’ll want your task to extend from ConventionTask for this to work. There is some bytecode generation magic that allows this to work. Be aware though that this is not a public API. As for getters and setters, if you are implementing your task in Java you’ll just create getters/setters for your properties as per normal JavaBean conventions. You’ll then use the @Input annotations on the getters rather than the private instance fields.

6

If you have a moment, is this class right now, for both convention and incremental compilation? BEWARE: Please click through to github: It seems that discuss.gradle.org has cached old versions of the files and included them in the post.

Thank you!

7

The additional getter is just for incremental support.

8

@mark_vieira

I was just trying this code snippet which you had mentioned above on using @Input and @InputFiles annotation as an alternative to @InputDirectories
Here the files inside the directories are always considered as modified by IncrementalTaskInputs interface. Any idea on this ?
thanks.