Correctly annotate Gradle task in- & outputs and enable stricter plugin validation

[TheMrMilchmann]

Gradle's task input and output annotations should be applied to the accessors instead of the properties. Not adhering to this can cause funky behavior in the generated stubs. Examples of this can be found in the docs: https://docs.gradle.org/current/userguide/implementing_custom_tasks.html

Also adds missing annotations so that stricter validation passes.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[wing328]

thanks for the PR, which has been merged

[NielsDoucet]

@TheMrMilchmann was this tested with gradle 9? I'm seeing weird behavior when trying to configure GenerateTask instances using the kotlin dsl after upgrading from gradle 8.14.3 to 9.1.0.
Strangely enough the errors only appear for the templateDir and library properties.
Example errors:

• templateDir:

Script compilation errors:

  Line 077:     templateDir = file(project.layout.projectDirectory.file("templates")).path
                ^ Unresolved reference. None of the following candidates is applicable because of a receiver type mismatch:
                    fun ConfigurableFileCollection.assign(fileCollection: FileCollection): Unit

  Line 077:     templateDir = file(project.layout.projectDirectory.file("templates")).path
                            ^ 

  Line 099:         templateDir = tasks.openApiGenerate.flatMap { it.templateDir }
                    ^ Unresolved reference. None of the following candidates is applicable because of a receiver type mismatch:
                        fun ConfigurableFileCollection.assign(fileCollection: FileCollection): Unit

  Line 099:         templateDir = tasks.openApiGenerate.flatMap { it.templateDir }
                                ^ 

  Line 099:         templateDir = tasks.openApiGenerate.flatMap { it.templateDir }
                                                        ^ Cannot infer type for this parameter. Specify it explicitly.

  Line 099:         templateDir = tasks.openApiGenerate.flatMap { it.templateDir }
                                                                  ^ Return type mismatch: expected '@Nullable() Provider<out uninferred S (of fun <S : Any> flatMap)>?', actual 'Property<String?>'.

• library

  Line 106:         library = tasks.openApiGenerate.flatMap { it.library }
                    ^ Unresolved reference. None of the following candidates is applicable because of a receiver type mismatch:
                        fun ConfigurableFileCollection.assign(fileCollection: FileCollection): Unit

  Line 106:         library = tasks.openApiGenerate.flatMap { it.library }
                            ^ 

  Line 106:         library = tasks.openApiGenerate.flatMap { it.library }
                                                    ^ Cannot infer type for this parameter. Specify it explicitly.

  Line 106:         library = tasks.openApiGenerate.flatMap { it.library }
                                                              ^ Return type mismatch: expected '@Nullable() Provider<out uninferred S (of fun <S : Any> flatMap)>?', actual 'Property<String?>'.

[TheMrMilchmann]

@NielsDoucet This is not directly related to this PR, but there is indeed an issue blocking Gradle 9 compatibility. Gradle 9 uses nullability annotations to enforce generic bounds more strictly in some cases.

You're hitting this one:

The nullability of generic bounds is now handled strictly.

For example, you can’t use Property<String?> anymore because the T in Property is not nullable.

Another example is using a function from the Gradle API that takes a Map<String, *> parameter ; you could pass a map with nullable values before, you can’t do that anymore.

https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#jspecify

As I'm also interested in Gradle 9 compatibility, I'll see if I can quickly put a PR together to fix this, although I'm not sure how to do this in a backwards-compatible way.

[TheMrMilchmann]

I created #22050 to tackle this.