[jira] [Commented] (CLI-312) Inconsistent behaviour in key/value pairs (Java property style)

["Gary D. Gregory (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLI-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756317#comment-17756317 ] 

Gary D. Gregory commented on CLI-312:
-------------------------------------

[~mthmulders] 

Are we all squared away? Can this issue be closed?

> 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
>
> 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)