few points from a picocli beginner

[peutch]

Hi,

Moving from commons-cli to picocli both using annotation and programmatic API, it is really nice!

1. Using something very similar to the documentation regarding the add of the help subcommand, I got an 'help help' message like the following:

Displays help information about the specified command

Usage: Main help [-h] [COMMAND...]

When no COMMAND is given, the usage help for the main command is displayed.
If a COMMAND is specified, the help for that command is shown.

      [COMMAND...]   The COMMAND to display the usage help message for.
  -h, --help         Show usage help for the help command and exit.

Why displaying [COMMAND...] and not just [COMMAND], does help for multiple commands in one run possible?
Because in my simple test case, it always displays help for the first command only.
2. Could it be a long-term dev to have a third approach using an externalized declaration file similar to what is done in JPA/ORM for which can be used annotations, runtime/programmatic API, and XML (or another format)? Is there any standard that could be interesting to look at for this? (in the scope of CWL?)
3. I don't despair of making my case with many subcommands works using only the programmatic API!!

Thanks

[remkop]

Hi @peutch, thanks for your feedback! Glad you like picocli!

Hi,

Moving from commons-cli to picocli both using annotation and programmatic API, it is really nice!

1. Using something very similar to the documentation regarding the add of the help subcommand, I got an 'help help' message like the following:

Usage: Main help [-h] [COMMAND...]

Why displaying [COMMAND...] and not just [COMMAND], does help for multiple commands in one run possible?
Because in my simple test case, it always displays help for the first command only.

Good point, I guess it should be just [COMMAND]. Do you feel like providing a pull request to fix this?

2. Could it be a long-term dev to have a third approach using an externalized declaration file similar to what is done in JPA/ORM for which can be used annotations, runtime/programmatic API, and XML (or another format)? Is there any standard that could be interesting to look at for this? (in the scope of CWL?)

Not sure what you mean. An externalized declaration file for what? For the options? Or for the help message?
Note that picocli allows externalization of the default values, and has support for resource bundles.

What problem are we trying to solve here?

3. I don't despair of making my case with many subcommands works using only the programmatic API!!

No despair is good! :-)
But your comment seems to indicate that there is a problem with the annotations API, did I understand that correctly?
If not, that is great, but if there is a problem, can you clarify what it is?

[peutch]

Hi @peutch, thanks for your feedback! Glad you like picocli!

Hi,
Moving from commons-cli to picocli both using annotation and programmatic API, it is really nice!

1. Using something very similar to the documentation regarding the add of the help subcommand, I got an 'help help' message like the following:

Usage: Main help [-h] [COMMAND...]

Why displaying [COMMAND...] and not just [COMMAND], does help for multiple commands in one run possible?
Because in my simple test case, it always displays help for the first command only.

Good point, I guess it should be just [COMMAND]. Do you feel like providing a pull request to fix this?

That's #1370.

1. Could it be a long-term dev to have a third approach using an externalized declaration file similar to what is done in JPA/ORM for which can be used annotations, runtime/programmatic API, and XML (or another format)? Is there any standard that could be interesting to look at for this? (in the scope of CWL?)

Not sure what you mean. An externalized declaration file for what? For the options? Or for the help message?
Note that picocli allows externalization of the default values, and has support for resource bundles.

What problem are we trying to solve here?

No problem, just new «facility». Suppose you have sort of META-INF/picocli.xml defining 'rootcmd' the main/top command.
Then:
public static void main(String[] args) { System.exit(new CommandLine(CommandSpec.createCommandSpecFactory("rootcmd").create()).execute(args)); }
The point would be to avoid modifying existing code to add annotation (more over if it is not owned classes) or to create annotated wrapping classes, or neither to write all the code using the programmatic API.

1. I don't despair of making my case with many subcommands works using only the programmatic API!!

No despair is good! :-)
But your comment seems to indicate that there is a problem with the annotations API, did I understand that correctly?
If not, that is great, but if there is a problem, can you clarify what it is?

Not a problem here also, I just got some difficulties with the programmatic API setting all the subcommands so to call their execute method and finally I went to create annotated wrapping classes for them.
Again, that's great!

[peutch]

And now also another last point (I think).

4. What do you think of embedding a CommandLine in a REPL? So that it would be an easy way to write like scripts (in a kind of script language) for the defined set of (sub)commands that would play the role of the $PATH in such script. I will be a gain to not have to call the same Java program many times in one SH script for instance. Moreover if needed, having a strategy to do System.exec for external command could be a fallback for any unknown defined command or to have a specific sh (sub)command. It would a bit different from bsh (BeanShell).
   Let see...

[remkop]

1. Could it be a long-term dev to have a third approach using an externalized declaration file similar to what is done in JPA/ORM for which can be used annotations, runtime/programmatic API, and XML (or another format)? Is there any standard that could be interesting to look at for this? (in the scope of CWL?)

Not sure what you mean. An externalized declaration file for what? For the options? Or for the help message?
Note that picocli allows externalization of the default values, and has support for resource bundles.
What problem are we trying to solve here?

No problem, just new «facility». Suppose you have sort of META-INF/picocli.xml defining 'rootcmd' the main/top command.
Then:
public static void main(String[] args) { System.exit(new CommandLine(CommandSpec.createCommandSpecFactory("rootcmd").create()).execute(args)); }
The point would be to avoid modifying existing code to add annotation (more over if it is not owned classes) or to create annotated wrapping classes, or neither to write all the code using the programmatic API.

Hmm, to be honest I am not interested currently in building such a facility.

And now also another last point (I think).

4. What do you think of embedding a CommandLine in a REPL? So that it would be an easy way to write like scripts (in a kind of script language) for the defined set of (sub)commands that would play the role of the $PATH in such script. I will be a gain to not have to call the same Java program many times in one SH script for instance. Moreover if needed, having a strategy to do System.exec for external command could be a fallback for any unknown defined command or to have a specific sh (sub)command. It would a bit different from bsh (BeanShell).
   Let see...

I should be possible to build something like that with the picocli-shell-jline<X> modules.
I suspect that the desired commands would be highly application-specific, so I feel this is more the area of applications rather than the area for the picocli library.