Emmanuel Bourg wrote:
> Emmanuel Bourg a écrit :
>
>> I'm going to convert the Avalon CLI test case to the Commons CLI API to
>> see what features are missing. I'll see if these features can be
>> implemented in CLI. So maybe we'll have a "common" API at last.
>
> I completed the conversion of the Avalon CLI tests to the Commons CLI
> API to compare the behavior of the 2 parsers. There were 36 test
> methods, 3 couldn't be converted due to a missing feature in Commons
> CLI, 4 methods fail due to a different behavior, and the rest just works.
>
> Here are the differences I noticed:
>
> 1. When 2 exclusive options of a group are in the same command line,
> Commons CLI throws an exception but Avalon CLI doesn't, it exposes an
> error message and the result of the parsing is available. With Commons
> CLI the exception prevents from accessing the result of the parsing.
>
>
> 2. Avalon CLI requires that optional arguments have an '=' separator.
> "--foo=bar" is ok but "--foo bar" isn't. I haven't checked but I guess
> it's the same with the short options (ie "-O1" vs "-O 1").
>
>
> 3. The PosixParser doesn't stop the parsing on the "--" token if the
> option preceding the token accepts an arguments, the token is used as an
> argument. The Avalon CLI parser and the GnuParser aren't affected by
> this issue.
>
>
> 4. There is no equivalent for the ParserControl interface in Commons
> CLI. It's used to interrupt the parsing on a specific option, or after a
> sequence of events.
>
>
> 5. Missing arguments are initialized to an empty string in Avalon CLI.
> For example with these options:
>
> OptionBuilder.hasArgs(2).withValueSeparator().create('D');
> OptionBuilder.create('c')
>
> and this command line:
>
> -Dfoo -c
>
> Avalon CLI assigns 2 values to the -D option, "foo" and "", but Commons
> CLI returns only one value.
>
>
>
> My quick analysis of these differences:
>
> 1. Avalon CLI warns and Commons CLI fails, I don't know if this is
> useful but we may probably add a setting in OptionGroup to ignore the
> error and continue the parsing.
>
> 2. I guess this restriction solves some ambiguous cases but it's also
> confusing for the end user, if he omits the '=' separator he may not
> understand why the value is not assigned to the option. I'm not sure
> it's worth implementing in Commons CLI, maybe as a parser setting or as
> an additional parser.
Hmmm. I always thought that using the long option the '=' is mandatory while
for a short option space is optional. See extract from "man diff" of GNU
diffutils:
========== %< ==============
-I RE --ignore-matching-lines=RE
Ignore changes whose lines all match RE.
--strip-trailing-cr
Strip trailing carriage return on input.
-a --text
Treat all files as text.
-c -C NUM --context[=NUM]
Output NUM (default 3) lines of copied context.
-u -U NUM --unified[=NUM]
Output NUM (default 3) lines of unified context.
--label LABEL
Use LABEL instead of file name.
-p --show-c-function
Show which C function each change is in.
-F RE --show-function-line=RE
========== %< ==============
> 3. PosixParser should be fixed
>
> 4. I ignore the use cases for this, I'll check the JMeter code to see if
> it's actually used. If this is proved useful this may be implemented in
> Commons CLI, but not before CLI 1.3.
>
> 5. Minor difference, can be easily worked around by an application
> migrating from Avalon CLI to Commons CLI
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
