Disallow setters for properties on parameter-like objects

[lptr]

This is a follow-up to #9068.

We want to encourage users to use mutable property objects instead of getter/setter pairs to configure parameter-like objects (tasks, artifact transforms, extensions, work items etc.).

So instead of this:

class MyTask extends DefaultTask {
    @InputFiles
    FileCollection sources
}

We'd want to support this:

class MyTask extends DefaultTask {
    @InputFiles
    final ConfigurableFileCollection sources
}

Conversely, instead of naked types like this:

class MyTask extends DefaultTask {
    @Input String name
    @Input int count
}

We'd like to migrate users towards Property types:

class MyTask extends DefaultTask {
    @Input final Property<String> name
    @Input final Property<Integer> count
}

We should thus issue warnings about any setter for a parameter value with a recommendation to use the corresponding mutable property type.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[stale]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Gradle or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request.

[wolfs]

I think we still want to do this.

[lptr]

Let's consider deprecating this for 7.0, too.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.