swagger-api / swagger-api/swagger-codegen
[Question]: Use existing java pojos located in different packages
Nobody has claimed this yet.
- Dominant language
- Mustache
- Stars
- 17.8k
- Forks
- 6k
- PR merge metrics
- No merged PRs in 30d
Description
Question
I have a lot of apis resources in a legacy springboot service. I wanted to create a openapi contract for all these apis. There are some java pojos used for requests and responses. They is some custom logic within it, which is used in several places. Can't put them into openapi schemas for auto generation.
So found out that we can user importMappings option to do that. It worked for one class classA, but generated as Object in other places for classB , classD.
classA , classB and classD are not in the same package.
Swagger Codegen Version
3.0.47
Language / Generator
Org custom generator
OpenAPI/Swagger Spec
schemas.yaml
openapi: 3.0.0
components:
schemas:
ClassA: {}
ClassB: {}
ClassD: {}
plugin in pom.xml
<plugin>
<groupId>io.swagger.codegen.v3</groupId>
<artifactId>swagger-codegen-maven-plugin</artifactId>
<version>3.0.47</version>
<executions>
<execution>
<id>model-codegen</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<language><--Custom--></language>
<inputSpec>${project.basedir}/src/main/resources/api/schemas.yaml</inputSpec>
<output>${project.build.directory}/generated-sources</output>
<generateModels>true</generateModels>
<generateApis>false</generateApis>
<generateApiTests>false</generateApiTests>
<generateModelTests>false</generateModelTests>
<generateApiDocumentation>false</generateApiDocumentation>
<generateModelDocumentation>false</generateModelDocumentation>
<generateSupportingFiles>false</generateSupportingFiles>
<!-- import java POJOs -->
<importMappings>
ClassA=com.org.request.ClassA,
ClassB=com.org.response.ClassB,
ClassD=com.org.lib.response.ClassD
</importMappings>
<typeMappings>
ClassA=com.org.request.ClassA,
ClassB=com.org.response.ClassB,
ClassD=com.org.lib.response.ClassD
</typeMappings>
<configOptions>
<ignoreImportMappings>false</ignoreImportMappings>
<preAuthorize>hasAuthority</preAuthorize>
<useJsonPropertyOrder>true</useJsonPropertyOrder>
<useJakarta>true</useJakarta>
</configOptions>
</configuration>
</execution>
<execution>
<id>openapi-codegen</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<language><--Custom--></language>
<inputSpec>${project.basedir}/src/main/resources/api/openapi.yaml</inputSpec>
<output>${project.build.directory}/generated-sources</output>
<apiPackage>com.org.gen.api</apiPackage>
<generateModels>false</generateModels>
<generateApis>true</generateApis>
<generateApiTests>false</generateApiTests>
<generateModelTests>false</generateModelTests>
<generateApiDocumentation>false</generateApiDocumentation>
<generateModelDocumentation>false</generateModelDocumentation>
<generateSupportingFiles>false</generateSupportingFiles>
<!-- import java POJOs -->
<importMappings>
ClassA=com.org.request.ClassA,
ClassB=com.org.response.ClassB,
ClassD=com.org.lib.response.ClassD
</importMappings>
<typeMappings>
ClassA=com.org.request.ClassA,
ClassB=com.org.response.ClassB,
ClassD=com.org.lib.response.ClassD
</typeMappings>
<configOptions>
<ignoreImportMappings>false</ignoreImportMappings>
<preAuthorize>hasAuthority</preAuthorize>
<useJsonPropertyOrder>true</useJsonPropertyOrder>
<useJakarta>true</useJakarta>
</configOptions>
</configuration>
</execution>
</executions>
</plugin>
I have referenced ClassA as the request body, then it generated an interface with a method which takes Object body (actual) as parameter instead of ClassA body (expected).
What I need from swagger codegen
I need it to generate api interfaces by using the exisiting java pojos, irrespective of their packages in the service. is that possible ? I don't want to change the classes that are in use, as it is used in many places, trying to avoid major code changes.
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
Reproduce the two Maven executions described in pom.xml using schemas.yaml and openapi.yaml, focusing on the importMappings and typeMappings for ClassA, ClassB, and ClassD. Compare the generated API interface's Object body with the expected ClassA body and inspect the custom generator's mapping behavior; done means the cause and supported behavior are established.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, spring-boot
- Domain
- api, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100