Add Java client generated from Swagger Codegen CLI
opened this issue · comments
It is possible to generate Java clients using Swagger Codegen CLI (swagger-codegen-cli), and we should add description on how to do it and sample configurations.
Can you provide some further details / code samples that would outline what you were thinking?
First, we need to demonstrate how to build Java clients with different network libraries, and list as a best practice specific libraries for Android and Java EE. I'd suggest to mention okhttp-gson, jersey2, retrofit2 and volley.
Second, IMO the "io.swagger.client" for the package name is too generic and potentially disruptive for projects that would use more than one different Swagger-generated clients, we need to recommend to give it a descriptive unique package name.
Third, the sample completely ignores the fact that this is the SEMP Config API and there are two more that could be used from the same client application.
Last, as a consumer of samples I would prefer to have each sample in a separate class/file instead of one "JavaClientSample" that it MsgVpnApi-centric and will bloat.
Also I could list a few confusing naming and strange coding style choices.
This could be also extended with building using the gradle-swagger-generator-plugin - see at https://github.com/int128/gradle-swagger-generator-plugin. One could go as far as fetching the swagger.yaml from the router and create the ready-to-use semp Java or other native language Client Library where the next step is to rebuild the sample code with the new library version.
What if I don't use Gradle?
What if I don't want to have my build process depending on a 3rd party product?
What if I don't want to have my build process depending on a 3rd party product done by somebody with a picture of his pet rabbit as an avatar?
How is it simpler than writing a few lines of the custom specification?
Balazs is going to work on this. Plan is to have a single gradle build that can conveniently build the client libraries in any language or in all languages and deploy them to a known subdirectory. The samples will then be updated to look for the client library in this location. The build should pull the SEMP schema from the dev portal and show how it can be updated to pull it from a Solace message router.
Reference to my approach to it:
https://github.com/dfedorov-solace/solace-semp-config-begin/tree/master/java
It doesn't use Gradle.
It doesn't have the build process depending on a 3rd party product.
It doesn't have the build process depending on a 3rd party product done by somebody with a picture of his pet rabbit as an avatar.
It is as simple as writing a few lines of the custom specification.