How to annotate Output result that is not a file or directory

Question

Cross post of https://discuss.gradle.org/t/how-to-annotate-output-result-that-is-not-a-file-or-directory/40515

I have a plugin that I am updating for Gradle 7 and need to annotate all of the properties with Input or Output. I first blanketed everything with Input, but realized that was wrong and some are Output…however not Files. The concrete example is here: https://github.com/JustinPihony/gradle-aws-plugin-reboot/blob/master/src/main/java/jp/classmethod/aws/reboot/gradle/lambda/AWSLambdaInvokeTask.java#L68

So, how am I supposed to make the invokeResult property annotated with Output?

Answer 1

I believe I found the answer -- and that is that I should use the @Internal annotation. The naming was what had thrown me off originally. I never looked into it because my assumption was that Internal would change the accessibility - however it seems that this annotation is merely to mark a property as one where the output isn't considered towards up-to-date-ness.

Answer 2

To answer your question: you don't. @Output is used for up to date checking, and should always be a file or collection of files (which can be derived from a dir/path). This has to do with the way up to date checking works. As far as I know it works by hashing all the inputs (files, objects, anything really) and combining it into an input hash and also taking all the output file paths into a single output hash. When the task is run again all those inputs are re-hashed to check if they are different, if not, all the files in the output are checked for existence and hashed, or if its just a dir all the files in there are hashed again to compare against the output hash. If all is the same the task is not executed.

Now if your task would also generate something (say a string) that is not saved in a file, the output could never be hashed without first running the task again, which would make up to date checking impossible.

So in short: all outputs have to be files.

Now, in your situation, your tasks have a bunch of configuration properties (some which are not used btw) which (except for maybe logType) look like input properties.