[CLI] Make -D option's syntax more similar to Java's system properties

[ePaul]

Current situation

There are currently two ways of passing system properties (which are used for language specific parameters, as well as for some options to the DefaultGenerator class) to Swagger Codegen, when using the CLI:

• Use Java's standard way, -D options in the command line before the class name (or -jar).
• Use Swagger-Codegen-CLI's -D option in the command line after the generate command.

Unfortunately those have different syntaxes, thereby confusing users and making certain uses more complicated than needed.

• Java's option can be given multiple times, each time with a pair of name and value (separated by =), or just a name (which then gets the empty string as a value).
• Swagger-Codegen-CLI's option can only given once (if given several times, just the last one wins), and takes a comma-separated list of name-value pairs. If you give just a name (without the =), it is just ignored.

Swagger-codegen version

2.2.2, as well as current master.

Command line examples

These examples are from the Readme. I omitted the values for -jar (the swagger-codegen-cli.jar) and -i (the API definition YAML or JSON) for clarity.

Generate only models and supporting files, no API:

# works already:
java -Dmodels -DsupportingFiles -jar ... generate -l java -i ...
# doesn't work yet (completely ignores both options)
java -jar ... generate -l java -i ... -Dmodels -DsupportingFiles
# doesn't work yet either (completely ignores both options)
java -jar ... generate -l java -i ... -Dmodels,supportingFiles
# needs to be written this way:
java -jar ... generate -l java -i ... -Dmodels=,supportingFiles=

Generate only one model and one supporting file, nothing else:

# works already
java -Dmodels=User -DsupportingFiles=StringUtil.java -jar ... generate -l java -i ...
# doesn't work (models=User is ignored)
java -jar ... generate -l java -i ... -Dmodels=User -DsupportingFiles=StringUtil.java
# needs to be written this way:
java -jar ... generate -l java -i ... -Dmodels=User,supportingFiles=StringUtil.java

Proposal

Extend swagger-codegen's syntax to ...

• allow multiple -D options (merging their key-value pairs – in case of conflicts the last ones would win)
• allow keys without = and values (giving an empty string as value).

For backwords-compatibility, I would still parse commas as separators in -D's values.

This would make all the CLI examples given above work.

(There would be a minor incompatibility, if someone relied on this strange behavior of having some keys (and values) ignored.)

Related issues

In my solution to #4788 I'm trying to get rid of using Java's system properties to store/pass those values to the Codegen classes (in order to be able to use multiple Codegen runs in the same JVM with different options), but I would still accept both Java's system properties and our own -D options as input. (The latter ones would just not be stored in actual system properties.)

We might later have a look on applying the same principle on other comma-separated key-value pairs, like type mappings, import mappings, reserved word mappings.

Suggest a Fix

I'll submit a PR in the next days – it seems like some minor changes in Generate, CodegenConfiguratorUtils + OptionUtils should be enough. The Airline library, which we use for command line parsing, already supports multiple occurrences of the same option.

[ePaul]

Actually,

 java -jar ... generate -l java -i ... -Dmodels=,supportingFiles=

doesn't even work (currently), this still ignores both properties.

On the other hand, it looks like fixing this for system properties in a straightforward way (changing OptionUtils.parseCommaSeparatedTuples) would also automatically effect other command line arguments which take comma-separated key-value-pairs. I don't see this as a big problem, although there are tests to ensure this behavior.