Remove circular dependency between swagger codegen and swagger codegen generator repos.

[HugoMario]

Description

for 3.0.0 version, swagger codegen use languages packs (classes and templates) in a different (a new one) repository swagger-codegen-generators.

Based on #6077, language classes from new repo must implement an interface located on swagger-codegen repo CodegenConfig. But cliand generator modules require dependency to swagger-codegen-generator in order to work properly. So as a result this is creating a circular dependency between repos.

Swagger-codegen version

3.0.0

Related issues/PRs

#6077

Suggest a fix/enhancement

So right now i see three ways to solve this.

1. This new repo would contains the interface and a few classes related to it. Swagger codegen core module and swagger codegen generator repo would point to this new one.

2. Move CodegenConfig interface to swagger-codegen-generator repo. Cause that's the key to points to swagger-codegen core module from swagger-codegen-generator repo.

3. Remove swagger-codegen-generator dependency from cli and generator modules. None class for swagger-codegen-generator repo is used in any of the swagger-codegen modules, the dependency is used in order to add generator classes in classpath.
   So, changing the way the CLI command is used it could be a way to solve this. i.e

java -cp [generator jar file location]:target/swagger-codegen-cli.jar [Main class here] generate -i [definition] -l java -o [folder]

With this command we're adding the classes to the classpath without the need to add a dependency to swagger-codegenmodules. The challenge is doing something similar for plugin and generator modules. Also a .sh/.bat files to wrap that call can be useful.

[HugoMario]

hey @jmini , would like to know what you think about this, or if you have an idea to share.

[jmini]

About 3: not practicable in my opinion. The cli jar is for the moment a fat jar that contains the generators and all others dependencies. This way it is easy for the user to use. They download only one single jar and start it.

With the new solution, how will they get the appropriate jar? (and update it, when you told them to check if their issue was fixed).

[jmini]

More generally: I think this is a nice analysis.

I would like to see the integration tests in this big picture. When you update the generators, you need to update the /samples folder. How will you solve this?
See also: swagger-api/swagger-codegen-generators#61

[HugoMario]

hey @jmini sorry for this late response.

About option 3, what i have in mind is creating an sh file to keep things easier. I guess the problem with that is we would need to keep on updating the file to point the update jar. But it could be viable, still not decided thought.

According what solution we take i guess same will be related to samplesit's possible that they don't required any change.

[a1dutch]

Hi, any progress on removing this circular dependency? i would like to write some custom language packs and be able to package them inside the plugin, generator and cli.

[wjase]

Ideally, the specific language packs wouldn't be packaged in the generator but downloaded from somewhere like maven central based on group:artifact:version coordinates and bound via interfaces at runtime. That way you have extensibility baked in. The core generator tests should probably not depend on any actual generators but instead on a special reference test generator which checks whether the core is calling all the right methods on the generator interfaces... If you still want a single jar for the 'default' langs in the cli jar then you could package a special fat jar, but do it in a project which depends on both the core and the generators you wish to bundle... just a thought.