Open jontejj opened 11 years ago
+1, the scenario I have is specifying the log level: it doesn't make sense to allow --warn, --error, --info, etc. CommonsCLI supports this via option groups but incompatibleWith would do just as well. Some thought needs to go into working out how to display help usage, e.g.: [ --warn | --error | --info ]
@paulk-asert sorry for the very long delay :( I went on a hiatus for a while there :)
Your specific case can be solved with what exists already, with something like this:
private enum LogLevel
{
error,
warn,
info
}
@Test
public void testEnumArgumentWithSeparator()
{
Argument<LogLevel> logLevel = enumArgument(LogLevel.class).defaultValue(LogLevel.error).separator("").ignoreCase().names("--").build();
Argument<String> conflictingName = stringArgument("--other").build();
CommandLineParser clp = CommandLineParser.withArguments(logLevel, conflictingName);
clp.usage().printOn(System.out);
LogLevel chosenLevel = clp.parse("--error").get(logLevel);
assertThat(chosenLevel).isEqualTo(LogLevel.error);
}
Usage looks like:
Usage: RemoteTestRunner [Arguments] Arguments: --<LogLevel> <LogLevel>: {error | warn | info} Default: error --other <string> <string>: any string Default:
But I'm sure there are other use cases for this feature though :)
Makes it illegal to pass in this argument when there's another incompatible argument given.