swagger-api / swagger-api/swagger-codegen
[JAVA] [library:vertx] Feature: Make possible for client generated code to share code
Nobody has claimed this yet.
- Dominant language
- Mustache
- Stars
- 17.8k
- Forks
- 6k
- PR merge metrics
- No merged PRs in 30d
Description
Description
If swagger-codegen is used to generate several clients (specifying different output folders, otherwise every new client overrides the previous one), each one generates its own ApiClient, ApiException, Configuration, Pair, RFC3339DateFormat, and StringUtil classes, though only ApiClient is actually client specific (including specific URLs, auth, etc.). This creates two problems: 1) there are many more classes than needed 2) I cannot share code that invokes different APIs (except if using reflection, which is really not ideal).
Swagger-codegen version
2.3.0-SNAPSHOT (using swagger-codegen-maven-plugin)
Command line used for generation
Maven pom.xml:
<plugin>
<groupId>io.swagger</groupId>
<artifactId>swagger-codegen-maven-plugin</artifactId>
<version>2.3.0-SNAPSHOT</version>
<execution>
<id>generate-client1</id>
<phase>generate-sources</phase>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<inputSpec>src/main/client1.yaml</inputSpec>
<apiPackage>io.swagger.client.client1.api</apiPackage>
<modelPackage>io.swagger.client.client1.model</modelPackage>
<invokerPackage>io.swagger.client.client1</invokerPackage>
<language>java</language>
<library>vertx</library>
</configuration>
</execution>
<execution>
<id>generate-client2</id>
<phase>generate-sources</phase>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<inputSpec>src/main/client2.yaml</inputSpec>
<apiPackage>io.swagger.client.client2.api</apiPackage>
<modelPackage>io.swagger.client.client2.model</modelPackage>
<invokerPackage>io.swagger.client.client2</invokerPackage>
<language>java</language>
<library>vertx</library>
</configuration>
</execution>
Related issues/PRs
https://github.com/swagger-api/swagger-codegen/issues/6741
https://github.com/swagger-api/swagger-codegen/pull/6742
Suggest a fix/enhancement
We might want to split invoker-package into invoker-package and invoker-common-package and move all but ApiClient into invoker-common-package. One could then point invoker-common-package of all invocations to be into the same folder, where there will be only one version of these. Also, it might then worth allowing control of whether to output these common, a la: -DcommonInvoker=false to expedite generation and avoiding overriding the same files.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the two generate executions in pom.xml and compare the client-specific and shared classes listed in the issue. Review related issue #6741 and pull request #6742 before deciding how shared output should be configured. Done means multiple Vert.x Java clients can share one copy of the common classes while retaining separate ApiClient classes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100