Introduce PicoCLI for parsing CLI arguments #875
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note this is only fully replaced for the Admin CLI adapter to start with.
The Enclave and Default CLI adapter can come after we are happy with it.
Until this time, there is some duplication of functionality, e.g. PID file parsing.
PicoCLI allows for a top level command, and then nesting commands under it.
For example,
tessera admin -addpeer <url> -configfile <path>
has 3 commands:tessera
- the main "top level command", given by DefaultCliAdapteradmin
- the first subcommand, given by AdminCommand and included in the top level command.-addpeer
- the next subcommand, put under AddPeerAction. This one is a bit annoying, since we decided to go with combining the action and parameter in the same argument. It would have been more idiomatic to use ... addpeer -url ..., but has been kept for backwards-compatibility.The ability to create a PID file is common functionality. It has been included in the addpeer command directly, instead of being at a common point higher up in the tree (i.e. having it apply to every subcommand automatically), because I haven't figured out yet if thats possible.
New commands can remain entirely separate, and only need to worry about themselves. A reference is added the parent command, and the library takes care about invoking it.
Below is an example of how the subcommands are laid out and routed, including some that don't exist for explanation purposes.
Notable user differences:
help messages have more information, but are limited to the (sub)command they are displaying, instead of showing everything at once. (like git help shows all top level commands, git help add shows only the add subcommand help)
command line args are ordered to the command they are for, instead of being in any order. e.g.
java -jar tessera.jar -configfile <path> admin -addpeer <url>
becomes
java -jar tessera.jar admin -addpeer <url> -configfile <path>
so whilst this may be considered breaking, it is small and actually enforces more standard usage.
Part of #874