[ https://issues.apache.org/jira/browse/CLI-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17445050#comment-17445050 ]
Maarten Mulders commented on CLI-312: ------------------------------------- {quote}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. {quote} Ah, interesting, we didn't spot that one, but that would make Mavens code even cleaner. Regardless of whether we use {{getOptionProperties()}} or {{getOptions()}} ([as we did in the PR|https://github.com/apache/maven/pull/605/files#diff-b8b814f5b6b3855ae79dc45a0266b94871193dcef42803c316e07409e94af35c]) the issue reported here remains... > 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)