This message was deleted.

For such things I usually have in the task class a

@Optional
@InputFiles

getter that calculates the dependencies from the input file and returns the files. If the calculation is really triggered multiple times (don't remember right now) you could add a simple hash based cache.

Thanks for the quick answer. Regarding the cache: that sounds like a good idea to prevent multiple calls to the file-reading logic. But I do not think that the annotated getter solves the main problem that the file-reading logic is triggered in the configuration phase. Indeed it seems to behave the same as registering the transitive files lazily from within the constructor, meaning that the input-file still will be evaluated in the configuration phase (probably due to implict-dependency calculation) and not only for up-to-date-checks right before executing the task. Here a small example how the getter looks like together with the input file property:

@InputFile
    @PathSensitive(PathSensitivity.NAME_ONLY)
    public Provider<Path> getInputFile() {
        return this.inputFile;
    }

    public void setInputFile(final Path inputFile) {
        this.inputFile.set(inputFile);
    }

    @Optional
    @InputFiles
    public Provider<ConfigurableFileCollection> getAdditionalInput() {
        return this.inputFile.map(inputFile -> {
            final List<Path> calculatedAdditionalPaths = new ArrayList<>();
            // read additional input paths from inputFile
            System.out.println("-> Calculation called");
            return getProject().files(calculatedAdditionalPaths);
        });
    }

The output of the project configuration:

...
All projects evaluated.
Selected primary task 'build' from project :
-> Calculation called 
Tasks to be executed: ...

I also tried it in a non-lazy fashion, but there was no difference. Do you maybe know how to avoid that call of the getter during configuration phase?

I don't remember when Gradle queries them. But your getter is only executed when someone needs the input files. Where the call comes from you can easily find out by setting a breakpoint in your getter and look at the stacktrace.

Yes, its queried by the TaskDependencyResolver, that I already knew, but I try to exclude the calculation from that query somehow, because I know that the task has no implicit dependency to another tasks output (at least for that property), because I calculate that input myself. I only want that input to be considered during up-to-date checks.

I'm not sure, but I don't think you can influence that except maybe with really dirty hacks like looking at the execution stack. But why do you actually care, especially when you do the caching thing? Also isn't the task dependency resolver just quering the inputs if the task is in the execution plan already, so the inputs need to be queried anyway?

Yes, that's true, it is only querying them if it's in the execution plan, therefore it may indeed be an acceptable solution. The only disadvantage I can think of then is that a dry-run might be slower, because of the file-evaluation which is triggered. But I guess that's something I can live with. Thanks for the support.

yw