Maarten Mulders created CLI-312:
-----------------------------------
Summary: Inconsistent behaviour in key/value pairs (Java property
style)
Key: CLI-312
URL: https://issues.apache.org/jira/browse/CLI-312
Project: Commons CLI
Issue Type: Bug
Components: Parser
Affects Versions: 1.5
Reporter: Maarten Mulders
In the Apache Maven project, we used to have an {{Option}} defined like this:
{code:java}
Option.builder("D").longOpt("define").hasArg().build()
{code}
This allowed our users to define properties using all of these:
* {{-Dx=1}}
* {{-Dx}}
* {{-D x}}
* {{--define x=1}}
* {{--define x}}
Splitting the key/value pairs was something that we did inside Maven
([{{MavenCli.java
#1733}}|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1733]
and [{{MavenCli.java
#1762}}|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1762]).
In the process of upgrading to Commons CLI 1.5 and moving away from the
deprecated {{GnuParser}}, we found out that Commons CLI can split argument
values thanks to the {{valueSeparator}}. We've changed our option declaration
accordingly:
{code:java}
Option.builder("D").longOpt("define").numberOfArgs(2).valueSeparator('=').build()
);
{code}
Unfortunately, this breaks our accepted inputs: {{-Dv -Dw=1 -D x=2 -D y -D
z=3}} breaks the parsing in Commons CLI:
{code}
org.apache.commons.cli.MissingArgumentException: Missing argument for option: D
at
org.apache.commons.cli.DefaultParser.checkRequiredArgs(DefaultParser.java:231)
at
org.apache.commons.cli.DefaultParser.handleOption(DefaultParser.java:394)
at
org.apache.commons.cli.DefaultParser.handleShortAndLongOption(DefaultParser.java:467)
at
org.apache.commons.cli.DefaultParser.handleToken(DefaultParser.java:542)
at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:714)
at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:681)
at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:662)
{code}
>From debugging, I've learned that it breaks at the *fifth* occurrence of
>{{-D}} (the one followed by {{z=3}}). It considers the *fourth* occurrence of
>{{-D}} incomplete (having only one value and not two). The strange thing is
>that the *first* occurrence of {{-D}} also has just one value ({{v}}) but
>parsing {{-Dw=1}} does not break over that.
I can submit a pull request for a bug that demonstrates this, but I have no
clue how to address it. Also, I don't know if this is actually supposed to
work. Looking forward to your reaction.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
