[
https://issues.apache.org/jira/browse/CLI-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved CLI-312.
---------------------------------
Fix Version/s: 1.7.0
Resolution: Fixed
[~mthmulders]
Fixed in git master with PR https://github.com/apache/commons-cli/pull/233
Please verify and close.
> 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.0
> Reporter: Maarten Mulders
> Priority: Minor
> Fix For: 1.7.0
>
>
> 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.10#820010)
