Package org.opends.server.util.args Description
Provides an implementation of a utility that can manage the processing of command-line arguments for an application.
This class centralizes a significant amount of processing so that it does not need to be repeated in all tools
requiring this kind of functionality, as well as helping to ensure that the interaction with program arguments is in
compliance with Sun's CLIP specification.
Features offered by this argument parsing implementation include:
- Arguments can be denoted using either a single dash followed by a single character or two dashes followed by a
more verbose multi-character token.
- The parsing performed on these arguments is very lenient so that it will likely be compatible with the style
preferred by the end user.
- Arguments are declared with or without a value, and the parser can be used to ensure that a value is provided for
arguments that require one.
- Each type of argument is associated with a particular data type, and a minimal amount of validation can be
handled by the argument parser itself in this case (e.g., if an argument is associated with an integer type, then
non-numeric values will be rejected, and it is also possible to define an acceptable range of values).
- The argument parser contains a built-in mechanism for ensuring that there are no conflicts between option names
(i.e., it ensures that two different arguments don't both try to use "-x" to invoke them).
- The argument parser contains a mechanism for allowing "extra" arguments at the end of the list which are not
explicitly associated with parameters. For example, in the ldapsearch utility, at least one of these "extra"
arguments would be used for the filter, and if there are any more of them then they would be used for the list of
attributes to return.
- The argument parser itself can generate usage information in a consistent manner so that it is not necessary for
each command-line application to explicitly provide this functionality.
A second version of the argument parser is also available which does not include support for trailing arguments but
does include support for the use of subcommands. In this case, you can define a number of subcommands each with their
own set of arguments. This can be used for cases in which one umbrella utility has a number of different capabilities
(e.g., the "cvs" command has a number of sub-commands like "checkout" and "commit" and "diff", each of which has its
own set of options).