Flag to stop parsing on first unmatched argument

I have a command line utility that discovers subcommands dynamically, based on the parameters given to the main command. In other words: I only know the list of available subcommands after parsing some of the command line parameters and doing some work, e.g. extending and then scanning the classpath.

Something like this: usage: cmd [--plugin-directory=PATH] <plugin-name> [plugin options]. Plugins are discovered dynamically based on the value of the --plugin-directory parameter.

This works (somehow) with picocli because it stops as soon as it finds an unknown parameter. This is exactly the behavior I need.

Currently I parse the command line in two steps: First I build a parser with setUnmatchedArgumentsAllowed(true) and parse everything up to the first unknown parameter. Then, I load config files, extend the classpath, discover all plugins and build a second parser. This time I can add all plugins and let picocli do its job.

With JCommander for example I cannot do this, because it would find plug-in parameters that have the same name as a main parameter and mix them together, regardless of their position, during the first parsing step.

I have some questions:

1. Is the picocli behavior (stopping at the first unknown parameter) intended, documented and can I rely on it, or is it just a coincidence?
2. Can I disable the warning about unused parameters or change the tracer level programmically?
3. Is there a better way?

[remkop]

I have changed my mind on this and I am planning to support a stopOnUnmatched flag (or similar, name may change).

[remkop]

Interesting use case. I’d like to support it.

Note that picocli’s parsing behaviour changed with the picocli 2.0 release to support mixing options with positional parameters on the command line.

As a result, I believe the latest version of picocli now works more similar to JCommander: unmatched commands are added to the list but parsing continues and picocli tries to match options encountered after the unmatched parameter (so it may apply these options to the top-level command).

1. I need to think a little about what would be the best way to support your use case. It could be as simple as a boolean flag stopParsingOnUnmatchedArgument, or it could be something more elaborate.
2. Currently there is no programmatic API to change the trace level, only system properties. There is also no way currently to switch off some warnings but not others. Improvements in this area could be part of the “more elaborate” solution to (1).

Thoughts?