[ https://issues.apache.org/jira/browse/CLI-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maarten Mulders closed CLI-312. ------------------------------- LGTM, thanks for the fix! > 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)