[
https://issues.apache.org/jira/browse/CLI-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17445035#comment-17445035
]
Robert Scholte commented on CLI-312:
------------------------------------
As of 1.5.0 [CommandLine.getOptionProperties(Option
option)|https://commons.apache.org/proper/commons-cli/apidocs/org/apache/commons/cli/CommandLine.html#getOptionProperties-org.apache.commons.cli.Option-]
should do exactly this.
> 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
> 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.1#820001)
