-
Notifications
You must be signed in to change notification settings - Fork 418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API to know all the commands #156
Comments
Please take a look at the |
Also, by default |
Is there similar api to to know all the commands i.e which are annotated with @command |
You mean in the classpath? You could iterate over all classes and query them with |
It may be easier to think of it this way: a Java program is started with a number of command line arguments. Think of the Java program as the top level command. In picocli this is the object that the Your program can understand some subcommands (and each of these can have nested sub-subcommands to any depth). When you create your program you know what subcommands it can handle. For each of these you call |
Instead of parsing every class, would it be possible for an api, which can do this during the annotation processing. This way, extra overheads at run time can be reduced |
Thanks for the interesting feedback and discussion on this ticket and #155. Currently, picocli is designed to have a hierarchy of subcommands in a tree structure, with a single I am aware of your proposal in #152 to register subcommands via annotations. The question raised in this ticket (API to know all commands) is one of the questions that need to be answered if we were to register subcommands via annotations. Perhaps we should make a note of that in the #152 ticket. Given the above explanation of the current picocli design, are you ok to close this question? |
(Sorry, I pressed the wrong button. Didn't mean to close this issue. ) Let's clarify our terminology to make sure we are talking about the same thing. In my view, a Java application has an entry point (the main method) which corresponds 1-on-1 with the main command. The name of the main command is not in the In this terminology, each Java application (a class with a main method) has only one main command. Does that match what you call main commands and subcommands? |
Remkop, the API needed for the situation as said in #155 i.e for usage of CLI in the following way
My observation in cli applications is that, Java Class (only one main method for all the CLI commands) and jar would be same. The subsequent parameter would be the main command. In above example, i see create_parking i.e. there is only one main method in the application, which knows what the main cli command is based on args[0] i.e first argument. |
In picocli, I should update the documentation to make this more clear. |
I took a look at your project. I now understand your use case a bit better. Basically, when the user requests help, you want to print the You solved this by taking the first I think that looks pretty good. If I can make a suggestion: why not pass the first Something like this:
The execute method signature would look like this:
Alternatively, you could pass the full |
Glad that you looked at my code.. Thank you so much. I can privately share you the code.. in case you already don't have I can follow your suggestion.. however, passing the reference in all the methods (I am assuming that, one of the called method also needs reference of allCommands in some context) called by execute() also demands change of signature to take allCommands reference as parameter. which is not advised.. |
In my code, I see the following as issues, w.r.t CLI, which i wish picoCLI to consider to enhance its api
|
|
3 & 4 use case I have discussed above
In such cli application where main method is only one, how do we print all commands help message (don't wish to create a virtual command) |
Thanks for the clarification. Can we rename this issue to "Add |
Sure. Thank U. |
|
sure Rem, is the latest jar pushed to maven |
I didn't make a release yet. Can you check out and build master to confirm? |
Tested with 0.9.8-SNAPSHOT.jar local jar, every thing works. |
Thanks for the confirmation. |
I am sure, most may not like it, However I do wish in similar lines to My thoughts on this is @command object is domain Object, it is nice to deal with this reference everywhere in application/solution rather than referring/passing |
I see your point. It would be nice to deal with the domain objects directly everywhere. We added For domain objects to be able to do this, they would need to implement some interface, but I don't want picocli to impose any restrictions on the domain objects. |
Ok then, on the the last point, the title of this issue:
You mention you need this in order to print a help message with all commands. Picocli gives you that ability if you create a main command and register your commands as subcommands. What I don't understand is why you don't want to do this. Furthermore, what if you have a JAR with two command line applications, each with a different set of subcommands? Automatically picking up all I really don't see any benefit in doing this... |
Creating main command and adding every others as sub command is a hack , also code is saying wrong relationships which are not real, but created to print messages of all commands. Presence of query API may avoid one main command class all together in every CLI application. |
No, this is not a hack. Every picocli application has a main command, even CLIs without subcommands. For example, this application has a main command without subcommands:
Note that the user never specifies the name of the main In your examples:
The user needs to specify |
Note that this is not just about printing a list of all commands. Your Application is a command line application, and as such it should probably have a usage help message by itself, so users can do the following and get general information about what the application does:
Your Application may support other global options, like
By making Application (or some other internal class) the main command, and |
(By the way, picocli-0.9.8 is now available for download from Maven Central. The user manual is also updated.) |
It is the time, we start re-defining main command differently in the context of picocli as it specific to java applications. I see Assume the other scenario too, what if I have a way to convert com.teja.Application into exe file say app.exe. Then I shall invoke the same command
My understanding is The way I wish PICOCLI to view main command is, any class which is annotated with @command annotation and potentially, we can take subcommands as the ones which are also annotated with @command and also added to another @command class through |
Doing what you're asking for would re-introduce a host of problems that are already solved with the current main command-subcommand hierarchy. What you describe as the benefit (ability to avoid one main command class all together in every CLI application) does not seem like a big problem. In fact, I am convinced that as soon as your application starts to have global options and global help, you will find that omitting the central main command is not even desirable and changing the design to support this would be a mistake. I'm going to mark this feature request as "won't fix" for now, until someone can show me a use case that cannot be accomplished with the current main command-subcommand hierarchy. (I mean, "I just don't want to create a central main command" is not enough reason for me to do this.) |
But again, thank you for the interesting discussions and good suggestions! Thanks to your input picocli now has a Thanks for your contributions, I greatly appreciate them! |
(I mean, "I just don't want to create a central main command" is not enough reason for me to do this.)Ok, if PICOCli wishes to enforce this, hope it could be documented, specially on the definition of main command which is always the first argument to java app, it needs to have @command and it also needs to have subcommands attribute taking all the commands in that application and has main() method. |
Sure, let me know what section in the user manual specifically needs to be clarified. |
This section can be refined http://picocli.info/#_introduction can be made as
|
Looking for an API to know all the commands defined. This can be helpful to print help message of all the commands in case customer asks for global help of all the commands
The text was updated successfully, but these errors were encountered: