[
https://issues.apache.org/jira/browse/CLI-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17444976#comment-17444976
]
Maarten Mulders commented on CLI-312:
-------------------------------------
{quote} if there's no separator nor value, then it'll represent the default
value {{true}}
{quote}
I think that is not true. With {{-Dv -Dw=x}}, from a Commons CLI perspective,
the first {{-D}} will have one value: {{v}}. The second {{-D}} will have two
values, {{x}} and {{y}}. Inside Maven, we
[interpret|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1762]
that as {{v=true}} and {{x=y}}.
> 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)
