为什么在使用 DefaultParser 而不是 GnuParser 时检测到的 CLI 选项不同?
我即将迁移一些遗留代码,以包含来自第三方库的较少弃用的警告。对于Apache库(版本:1.3.1),我在官方JavaDoc中检测到已弃用,应该改用:commons-cli
GnuParser
DefaultParser
@deprecated自 1.3 起,请改用
{@link DefaultParser}
但是,以下代码段将按预期方式停止工作:
Options options = new Options();
Option optionGSTypes = new Option(
"gst","gs-types", true,
"the supported types, comma-separated: article, category, template, all");
optionGSTypes.setArgs(3);
optionGSTypes.setValueSeparator(',');
options.addOption(optionGSTypes);
// ... other options
// parsed option values are correct, yet this is deprecated
CommandLineParser parser = new GnuParser();
CommandLine commands = parser.parse(options, args);
// ... interpret parsed 'commands' and related actual values via CLI
请注意,此处用于定义自定义分隔符 char,以使 CLI 能够支持 sevaral gst 类型(请参阅代码段)。setValueSeparator(',')
,
作为输入,以下程序参数用于调用 CLI:
java -jar MyCLI.jar -gst category -gsd 4
显然,在 gsd 参数之后可能还添加了其他几个参数。对于不使用分隔符的“gst”参数,预期和正确解析的选件是(通过):GnuParser
- “类别”(仅此而已)
但是,当我更改代码并通过以下方式切换到推荐的解析器时:
CommandLineParser parser = new DefaultParser();
生成的解析值被错误地检测为:
- “类别”
- “-gsd”
- "4"
提示:我使用调试器通过返回的变量检查中的字段来验证解析过程的错误结果。values
org.apache.commons.cli.Option
commands
我的期望是,解析器的内部更改不应该产生不同的结果,因为这会破坏现有的代码。有没有人在切换到和几个选项值和自定义分隔符时遇到过与Apache Commons-CLI相同的行为?DefaultParser
我可能已经监督的构造/使用是否有差异?DefaultParser