Support repeating composite arguments (was: Parameter options/modifiers)

Picocli supports mixing options and parameters: http://picocli.info/#_mixing_options_and_positional_parameters

I would like to know what options have been specified before certain parameter. Consider such command:

print --paper A4 A.pdf --count 3 B.pdf --rotate left C.pdf -- D.pdf --rotate right E.pdf

Where:

• --paper is an global option,
• --count and --rotate are “local” options, or parameter modifiers,
• -- reset local options.

So, that command would evaluate to:

• globals: paper = A4,
• parameter A.pdf: count = default, rotate = default,
• parameter B.pdf: count = 3, rotate = default,
• parameter C.pdf: count = 3, rotate = left,
• parameter D.pdf: count = default, rotate = default,
• parameter E.pdf: count = default, rotate = right.

Is there support for such things in picocli?

[remkop]

Picocli 4.0.0-alpha-1 has been released which includes support for repeating composite groups. See https://picocli.info/#_argument_groups for details.

Please try this and provide feedback. We can still make changes.

What do you think of the annotations API? What about the programmatic API? Does it work as expected? Are the input validation error messages correct and clear? Is the documentation clear and complete? Anything you want to change or improve? Any other feedback?

[bbottema]

--email:from name=String fromAddress=STRING

That’s the synopsis, but the invocation currently is:

--email:from "some string" "some address string"

In case it keeps working like this, then the answer to your question depends on the implementation of how arguments are referenced after parsing:

If these composite option values would have to be predefined (ie. a class with declared fields), then it would be useful and feasible to have optional fields (being referable by name). However, in my use case I prefer to leave to the composition unbounded (ie. an array of arbitrary number of types of mandatory parameter values). This is because I’m generating the composite signatures in runtime using reflection.

To illustrate, I prefer:

{ String.class, Integer.class, Boolean.class }

over:

class CompositeOptionValue {
   String a;
   Integer b;
   Boolean c;
}

Of course, you could work with a Map here:

"a" : String.class,
"b" : Integer.class,
"c" : Boolean.class

In this case the parsed arguments can be referenced by name but also generated by name in run time, in which case optional values are workable again. Without named arguments, it will become impossible to know which parameters of a java Method should be null.

In general though, I have to add that I don’t have many optional parameters, because that would imply that there is a different need than the API provides and I would simply add an overloaded more succinct version with that parameter left out.