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).