Unable to use @Option with ListProperty/SetProperty

[szpak]

Expected Behavior

@Option should be possible to use with final ListProperty/SetProperty<> fields (as it was implemented by @adammurdoch for Property<> in #7977).

Current Behavior

@Input
@Optional
@Option(option = "pitest-features", description = "Configures PIT features to be used")
final ListProperty<String> features //it's Groovy, getter is automatically generated

gives:

OptionValidationException: No setter for Option annotated field 'features' in class 'class info.solidsoft.gradle.pitest.PitestTask'.

Context

After migration from List<> and conventionMapping to PropertyList<> (or PropertySet<>) it is no longer possible to use @Option to set/override values.

Steps to Reproduce

Try to set value with @Option for final ListProperty<>/final SetProperty<> fileds.

Your Environment

Gradle 5.6.1.

[big-guy]

This looks like a good idea to me. Would you be willing to submit a PR?

[Vampire]

Maybe it would also make sense if you could somehow specify from the commandline, whether you want to replace any value set in the build script or add to the set or list of values.

Especially for my use-case from which this issues is grown of, I really want to add to the list configured in the build script and not replace the values.

[szpak]

--pitest.features+=YOUR_ADDED_FEATURE? I don't know if the @Option mechanism support that.

Update. --pitest.features instead of pitest --features as I hope to have that syntax supported one day (without the need po put it right after the task).

[Vampire]

I guess it does not yet, hence the comment here to maybe add it while adding support for ListPropery and SetProperty. :-)

Btw. I agree with @big-guy, that a "pitest" prefix for the options should not be used.
You already have to specify this option after the task the option is for, that should be enough association, no matter if a dot, dash or underscore is used to separate the prefix from the actual option name. This just adds the burden to type these characters on the command-line which is not really helpful imho. :-)

[big-guy]

I think the first step would be to make this work the same way as a regular List and then add something that would append separately. It's less confusing that they just work the same for now.

@Vampire could you open an issue (if you haven't already) for allowing list options to append? Some examples for where you'd like to use it would be helpful.

[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.

[szpak]

It is still relevant.

[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.

[lptr]

Looks like the behavior changed somewhat, but it still doesn't work as expected. From duplicate issue #25097:

Expected Behavior

It is possible to annotation a JavaBean property of type List<String> with @Option and supply it with values from the command-line. We should have feature parity for properties of type ListProperty<String> etc.

Current Behavior (optional)

Currently an error is thrown if @Option is used on ListProperty<String>:

Caused by: org.gradle.cli.CommandLineArgumentException: Command-line option '--serial' does not take an argument.
	at app//org.gradle.cli.CommandLineParser$KnownOptionParserState.onArgument(CommandLineParser.java:423)
	at app//org.gradle.cli.CommandLineParser.parse(CommandLineParser.java:93)
	at app//org.gradle.execution.commandline.CommandLineTaskConfigurer.configureTasksNow(CommandLineTaskConfigurer.java:67)
	... 123 more

Context

When migrating eager multi-valued properties from List<T> to lazy ListProperty<T> types we need to keep @Option working for them.