commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject [cli] Avalon CLI vs Commons CLI 1.x
Date Tue, 22 Jul 2008 17:59:06 GMT
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:


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.

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

Emmanuel Bourg

View raw message