Package org.opends.server.util.args
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:
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).
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).