Introduce config-based command line argument binding

[dmlloyd]

Description
Introduce a way to bind command line arguments to configuration values.

• Introduce an annotation or annotations to indicate that a @ConfigItem corresponds to a command line argument with long and/or short forms and the corresponding configuration property name, with a sensible default naming strategy for the long form (if any)
• Create a backing BuildItem to carry this information, which is produced by ExtensionLoader when the config items are discovered
• Create a ConfigSource implementation which accepts a String[] representing the command line arguments, and also provides access to a "cleaned" String[] with the predefined arguments removed (NOTE: this should be contributed directly to [SmallRye Config](https://github.com/smallrye/config - tag @dmlloyd on the PR)
• Configure the new config source from the build items and wire it in to the run time configuration setup (io.quarkus.deployment.configuration.RunTimeConfigurationGenerator)

Requirements

• Use a GNU-style argument form (essentially --arg-name=foo and --arg-name foo should both be allowed for long arguments with a simple value; -xfoo and -x foo are accepted forms for short arguments with required values; maybe consider optionally supporting the common --foo/--no-foo and/or --with-foo/--without-foo and/or --enable-foo/--disable-foo styles as well)
• Short arguments with no value should be supported corresponding to boolean properties e.g. -x (optionality can not be supported for these)
• Invalid or unrecognized argument names should trigger a descriptive IllegalArgumentException
• GNU allows short arguments with no value to be condensed like -a -b -c => -abc, but this does not need to be supported
• As per the GNU convention, an argument of -- indicates the end of the interpreted arguments (the rest of the arguments are passed through)

[dmlloyd]

There also should be a way to optionally bind the remaining arguments to a configuration item. It should automatically "listify" the values.

[maxandersen]

Will this auto-read of arguments and then removal before calling to user own "main" be forced or something that user can turn on/off ?

And how about when user have their own validation and shell completion support; like what picocli can provide - how would such libraries become aware of these "magical" property settings ?

[dmlloyd]

Will this auto-read of arguments and then removal before calling to user own "main" be forced or something that user can turn on/off ?

I would think it would probably be forced, otherwise we could end up with some truly bizarre behavior.

And how about when user have their own validation and shell completion support; like what picocli can provide - how would such libraries become aware of these "magical" property settings ?

I'm not sure what the right solution is for this, but I do know that this is a problem that has to be solved twice: once because we consume some arguments, and once again because GraalVM's main method consumes some more arguments.

[maxandersen]

and once again because GraalVM's main method consumes some more arguments.

oh - what are those ?

[maxandersen]

one way could be to pass arguments like this: --Q:propertyname=value so kinda like a java/mvn -D style arg passing. Not as "pure" but then the rule is simple that anything started with "--Q:" is a reserved argument ?

[dmlloyd]

and once again because GraalVM's main method consumes some more arguments.

oh - what are those ?

-Dxx=yy, -Xmx.., etc.

[maxandersen]

ah so doing -Qxx=yy wouldn't be that far fetched ?

[dmlloyd]

My list was not exhaustive and I definitely didn't mean to suggest that there is some uniform syntax for Graalvm arguments (afaik there isn't).

[magicprinc]

As source of inspirations
https://docs.spring.io/spring-boot/docs/1.2.0.RELEASE/reference/html/boot-features-external-config.html#boot-features-external-config-command-line-args

[maxandersen]

thanks @magicprinc it does seem like a simple way of doing it. and we could just do it and possibly provide a quarkus.arg-prefix one could set to i.e. '-Q` to keep it simple by default but enable users to avoid conflicts with their own cli "API".

wdyt @dmlloyd / @gastaldi ?

[gastaldi]

@maxandersen That sounds like it could work. Also, @dmlloyd's PR description seems on point to what needs to be done

[maxandersen]

@gastaldi different from what smallrye/smallrye-config#290 did/does?

[gastaldi]

@maxandersen I think it's similar, but missing the validation and parsing features specified. I remember checking https://github.com/jopt-simple/jopt-simple as an attempt to fulfill those requirements but it fell into the cracks