commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [cli] Avalon CLI vs Commons CLI 1.x
Date Tue, 22 Jul 2008 21:30:58 GMT
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

========== %< ==============
      -I RE  --ignore-matching-lines=RE
              Ignore changes whose lines all match RE.

              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:
For additional commands, e-mail:

View raw message