swagger-api / swagger-api/swagger-codegen

[JAVA] [library:vertx] Feature: Make possible for client generated code to share code

Open
#6,917 0 comments 0 reactions 0 assignees View on GitHub

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.