I love this library, but I've had to write a lot of gross, hacky code to support the following use case.
I have several small application where sometimes a certain parameter will be required, let's say a username, and sometimes it should NOT be required depending on whether or not another param exists.
Let's say we're getting a file, and the app supports both HTTP and FTP. For HTTP we might not need a username and password and for FTP we almost always would. It would be nice to specify that if FTP is specified, username and password must also be specified. Otherwise, they are optional.
I've held off on features like this for a while, because I didn't want to overcomplicate the API. However, now that OptionSpecs are part of the API, I'm interested in seeing about doing this.
What about something like:
requiredIf() could be overloaded to accept OptionSpecs as well as string representations of options.
Can you imagine a scenario in which a given option might become required if one of several different options are present on the command line?
This would also be useful in the case of a "-h or --help" option to print the help/usage screen...maybe someway to assign a "help" option that doesn't require any other options with it...
I'm open to the possibility of adding this feature. I'd like to get a sense of what API makes sense for the most requesters. I'm thinking of the above...maybe:
ArgumentAcceptingOptionSpec.requiredIf(String required, String... otherRequireds)
ArgumentAcceptingOptionSpec.requiredIf(OptionSpec<?> required, OptionSpec<?>... otherRequireds)
What do you think of this?
@Mrc0113, can you elaborate some more on the idea of a "-h" or "--help" option that doesn't require options with it?
If I have a class that requires several options I want the ability to be able to display the command line help without the user having to include all the required options. (they may need to view the command line help to understand what the required options are)
For example, right now I might have a class that requires 3 options [and also has a 'help' option which tells me to parser.printHelpOn(System.out);] but if the user types this:
java -cp .:jopt-simple-4.3.jar blah.blah.Main --help
He will currently get this:
joptsimple.MissingRequiredOptionException: Missing required option ['option1', 'option2', 'option3']
I'm not sure of the best way to do this...either be able to specify a "printHelpOn" option or give the ability to ignore required options in some cases....I could see that maybe being useful if someone wanted to include a -version option as well.
@pholser, I guess I didn't answer your first question above; but yes I do like the idea of having a .requiredIf option. I think that solves the issue this thread was opened for and could possibly be used for my issue of not having a way of just specifying the help option when other options are required (I'd just have to tie all the other options together using requiredIf)
Right on. I may tackle the help option bit under separate cover.
I've added #14 to track the bit about designating a "help" option that doesn't cause JOpt Simple to raise an exception if present but no "required" options are.
Thanks for #14 - I waited for it too. Do you plan to update http://central.maven.org/maven2/net/sf/jopt-simple/jopt-simple/ ?
Great library, by the way.
@MarkKharitonov Thanks! I'd like to get a couple more features in before declaring a 4.4 beta.
#12 offering OptionSpecBuilder.requiredIf(String|OptionSpec)
@ryonday @Mrc0113 There is a 4.4-SNAPSHOT jar deployed at https://oss.sonatype.org/content/repositories/snapshots/ -- if you have a minute, feel free to test-drive requiredIf().
Available in 4.4 beta 2