In the effort of adding option validation to gfsh commands (GEODE-1597) and simplifying gfsh parsing, I started this exercise of only using SpringShell's parser instead of a combination of springshell's, joptsimple's and our own parsers. The end result is a lot more manageable code base, and the capability to validate the option list, but does have these following different behaviors, and I would like the community's wight in on whether or not these are acceptable or not:
1) SpringShell doesn't allow you to specify an option twice, so for multivalued parameters, our old parser can accept command like "change loglevel --member=member1 --member=member2", but now the parser will give you an error, and you should only do "change loglevel --member=member1,member2". The new parser did something speical for --J option though, so for --J, you can specify it multiple times. 2) For value separator, springShell default's to ",", you can only overwrite it with option context "splittingRegex", we do not honor the @CliMetaData(valueSepartor=) anymore. All of our commands uses "," for separators, so this won't break our commands, but if there is any command out there that would define a different @CliMetaData(valueSepartor=) other than ",", SpringShell would not know how to parse it. 3) To specify empty string as parameter value, before you will need to do put region=A key="''" value="''" spring shell would think the value you are trying to pass in are two single quotes instead of empty strings, now, you should only do put region=A key="" value="" Cheers Jinmei
