commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Cager <>
Subject Re: Release of commons-cli?
Date Wed, 28 May 2008 20:27:29 GMT
Henri Yandell wrote:
> CLI 2.0 I don't see any time soon (ever) unless someone gets a big urge.
> CLI 1.2 I have on my list as a 'sometime soon' along with the next
> Collections 3.x and Codec 1.x - looking at it I think it could go very
> easily, none of the 4 tickets are blocked (ignoring that CLI-137 is a
> painful one to close as WONTFIX).

I have done some work on CLI-137 as part of the Debian packaging. I 
think it is quite a severe bug, as it does not allow you to handle (for 
example) multiple "-D" arguments (as found in Maven or ant).

I've prepared a patch for it for the Debian build (although I do not 
necessarily think that's the best way to fix it), and amended the JUnit 
tests to demonstrate the problem.

I sent an email to the -dev list a few weeks ago, but I think it might 
have gone missing. Here it is:


I've fallen over the CLI bug described in issue 137, and I'm wondering
if I can help provide a patch for it? I'd appreciate someone just
checking my logic in case I'm missing something obvious. I'm using
release 1.1, by the way.

As far as I can see it is simply not possible to use commons-cli to
parse repeating options, such as occur in ant:

      ant -Dproperty1=value1 -Dproperty2=value2 compile

Cli *does* have a junit test for ant-type options, but it unfortunately
doesn't catch the error because it tests the command line:

      ant -Dproperty1=value1 -Dproperty2=value2 -projecthelp

I attach a patch for the junit test (Cli-junit.patch) that will provoke 
the error, if you want to try it yourself.

_Here's what I think is happening:_

The unit test (and the work-around suggested in issue 137) creates the
"D" option using "hasArgs()" [note the 's' on the end of the method
name]. Using hasArgs() for the "D" option causes cli to assume that all
arguments following the "-D" (until it encounters another option) belong
to the "-D" option. I've probably not explained that clearly so here's
an example:

      ant -Dproperty1=value1 -Dproperty2=value2 compile

will treat "compile" as though it was "-Dcompile". getArgs() will return
0 elements, rather than one ("compile").

If instead you construct the "D" option using hasArg() [singular] then
it will *not* interpret the second "-D" as an option. getArgs() will
return 2 elements: "property2=value2" and "compile". getOptionValues()
will return only the first -D value.

This problem first came to light when Debian upgraded CLI from 1.0 to 
1.1, and caused Debian's Maven package to fail (the standard Maven 
package uses cli 1.0 of course). As part of the Debian packaging I have 
created a quick-and-dirty patch which allows Maven to work (see for the Debian 
bug report, and I have attached the patch (MultiOptions.patch). I would 
guess that a proper fix would be rather more elegant than my patch.

Paul Cager

View raw message