Make EvalTask track resolved output paths

[bioball]

This makes Gradle track getOutputPaths() and getMultipleFileOutputPaths. These represent the actual outputs of the EvalTask.

[translatenix]

I see no indication that EvalTask supports placeholders. It only accepts RegularFileProperty getOutputFile() and DirectoryProperty getMultipleFileOutputDir(), which clearly shouldn't contain placeholders.

[StefMa]

You can read it up here: https://pkl-lang.org/main/current/pkl-gradle/index.html#configuration-options

So yes it's a bit confusing that you can put a file into it that can contain a placeholder that doesn't work with Gradle because the file location is unknown at that point.

[translatenix]

This is a design mistake in EvalTask. Should try to fix that instead of making the task untracked.

[StefMa]

This is a design mistake in EvalTask. Should try to fix that instead of making the task untracked.

If we would use a normal String as input it would work right? 🤔

[translatenix]

I think EvalTask could have separate Property<String> properties and invalidate outputs if those are set. But I see that CliEvaluator has outputFiles and outputDirectories properties, which might be all that's needed for accurate tracking.

[bioball]

But I see that CliEvaluator has outputFiles and outputDirectories properties, which might be all that's needed for accurate tracking.

Great idea! Updated the PR to add new properties that are tracked.

[netvl]

Btw, let me correct myself - it seems I forgot the code base a bit - of course there can be multiple output files with single output pattern; then the logic would look like this:

  @OutputFiles
  @Optional
  public Provider<Set<File>> getEffectiveOutputFilePaths() {
      return cliEvaluator.map(CliEvaluator::getOutputFiles);
  }
  
  @OutputDirectories
  @Optional
  public Provider<Set<File>> getOutputDirectories() {
      return cliEvaluator.map(CliEvaluator::getOutputDirectories);
  }

~I also switched to Provider<Set<File>> instead of FileCollection, because unfortunately file collections are more cumbersome to create than providers, especially if empty providers is a possibility.~ Not true in the latest version of the PR, FileCollections are all right here.