I just released JCommander 1.3, here are the new features:
- @ResourceBundle is deprecated and replaced with @Parameters:
@Parameters(resourceBundle = "MessageBundle") public class ArgsI18N2New {I had to deprecate @ResourceBundle because I needed a more general annotation in order to implement the next new feature.
- You can now use different separators for your options:
java Main -log:3
or
java Main -level=42
You define the separator with the @Parameters annotation:
@Parameters(separators = "=") public class SeparatorEqual { @Parameter(names = "-level") public Integer level = 2; } - Parameters can now be hidden, in which case they will not appear in the usage:
@Parameter(names = "-debug", description = "Debug mode", hidden = true) public boolean debug = false;
- The usage output is now sorted alphabetically and cleanly aligned:
Usage: [main class] [options] list of files Options: -b, --bonjour enable Bonjour. -e, --export-preferences export preferences into the given file. -F, --flush-preferences flush gui preferences. -h, --help show this help. -i, --import-preferences import preferences from the given file.
Download either directly or with Maven:
com.beust jcommander 1.3
#1 by Dmitri on July 26, 2010 - 9:53 am
I really like JCommander – I’ve been switching back and fourth between 3 or 4 different command line parsers in my applications, and I’ve converted everything to use JCommander (it’s the first one I actually enjoy using).
One feature that would really come in handy – would it be possible to initialize common option defaults (say from a properties file)? I have multiple commands that have many options in common (the app picks the one to run based on a main argument), but may handle them differently (eg whether they are required or not, slightly different labels, etc), and I initialize these with override-able defaults specific to an environment, so users don’t have to re-enter the same values over and over again.
#2 by Maurice Zejen on July 26, 2010 - 10:14 pm
Thanks for another very useful library.
I have one feature request: More complex command line applications (like Subversion) often have ‘2 dimensional’ options. The first parameter defines which other parameters are possible.
In Subversion the command ‘svn add’ has different possible parameters then ‘svn log’.
To see which parameters are possible for a certain subcommand you need to execute: svn help
Supporting this in JCommander would be really great.
#3 by Cedric on July 26, 2010 - 10:21 pm
Maurice:
I’m wondering if the limitations of annotations (they can only use constants) would make it possible to define such a complex grammar… I’ll think about this more.
Thanks for the suggestion.
Pingback: Pedro Newsletter 26.07.2010 « Pragmatic Programmer Issues – pietrowski.info
#4 by James on July 27, 2010 - 5:55 am
A few requests…
1. Would be nice to display Usage if required parameters are not specified. Can’t do this now because parameter validation is part of the constructor and the constructor throws an exception.
2. Would be nice to display parameter type (int, string, boolean) in Usage.
3. Would be nice to display/note default value in Usage.
#5 by James on July 27, 2010 - 6:06 am
Forgot #4.
4. Would be nice to flag required parameters in Usage. (Maybe with a * ?)
#6 by Vladimir Shor on July 29, 2010 - 12:17 am
Very neat and light library!
+1 to Maurice’s feature request on command parameters.
Currently I have implemented a converter to enum values, to restrict possible command values, but I wonder where to stick the validation of parameter combinations. For some commands are required only some of options and other options are required for other commands, so ‘required’ flag of the Parameter annotation is not quite sufficient. What do you think of adding a custom validator class for the Parameter? Or are there any better alternatives?
#7 by Cedric on July 29, 2010 - 10:34 pm
I thought about providing a validator() method on JCommander that subclasses could override but that seemed overkill and without much added benefit. In TestNG, I just do this in a separate method.
As to your second question, I intentionally didn’t push too much validation semantics in JCommander (“required” is the only exception). The reasoning is that once you application becomes complicated, the validation logic can most likely not be expressed with the limited language of annotations, so you’re better off just writing the logic yourself in real code.
Hope this makes sense.
—
Cédric
#8 by Vladimir Shor on August 5, 2010 - 7:27 am
I found one very neat (at least IMO) solution for command parameters problem. I separated global parameters and command-specific parameters into different classes. And each command class contains it’s own parameters and validation logic (in this case some commands can require something and some do not). Then at first I detect the command, create commandObject and then by using a construct like this:
new JCommander(new Object[] {globalArgsObject, commandObject}, args);
initialize them. This way I have different commands and some global stuff and both can do what needed.
#9 by Larry H on May 19, 2011 - 3:13 pm
Jey ther thi has worked fine but im having a problem imputing this:”.
-F, –flush-preferences flush gui preferences.
-h, –help show this help.
-i, –import-preferences import ”
do you know what i may be doing wrong?