Replace '--generator-name' with multiple switches to select a generator

[jmini]

On the long term we might want to offer an other way to select the targeted generator.

Probably with multiple switches (to be defined more precisely):

• language
• generator type
• framework
• ...

Examples:

cli -type=client -language=kotlin
cli -type=server -language=kotlin -framework=ktor

A first step in this direction was made with #39, where we have renamed -l (--lang) into -g (--generator-name).

With the next version (4.0.0 ?) we might want to continue to work on this by providing an other way to lookup a generator with multiple switches.

This is open for feedback.

cc: @jimschubert

[jimschubert]

I think it would also be nice to offer suggestions.

For example, if you were to run the following on current master:

cli generate -type=server -language=kotlin

there's only ktor, so we could assume the user wants the ktor framework generator. As we add new frameworks, I think it would be good to inform the user and then require -framework explicitly.

As an example, if we add javalin and spring support, we could do something like:

Kotlin Server framework options include:
    - ktor
    - javalin
    - spring
Choose one of the above, or we'll continue in 5 seconds with the default (ktor):

[rienafairefr]

Each *Codegen class instead of having a single (getName()) key to select with -g, there would be more keys, getLanguage() and getFramework() and getTag() (this one already exists).

This is breaking change (changing CodegenConfig interface), but seems doable to me. We can keep the -g option to uniquely select a generator, and also add (-lang|-framework|-type) to get to a generator by its composite key. Error out when there is an ambiguity (e.g. multiple generators match that key), error out when there is too much data (e.g. there is a server with that language, but no client)

[jmini]

There is one thing that makes it a little more complex:
--lang was the old name for --generator-name (in swagger-codegen). So for backward compatibility you might need to keep this possibility until 4.0.0. But this is also not a blocker.

@rienafairefr : Yes I agree with you, it can be done even by keeping the generators the way they are. In later refactorings we can get remove the abstract codegen (AbstractKotlinCodegen, KotlinClientCodegen and KotlinServerCodegen by merging all in one, if this facilitate the way the generators are written -- this is in PR #852).