Bug Report Checklist
Description
I generated a client for a specification with a component called Consumer. The generator produced a client with import statements for both java.util.function.Consumer and a ...model.Consumer. As a result, the code cannot compile because the reference to Consumer is ambiguous wherever the Consumer type is referenced:
// in file org/openapitools/client/api/DefaultApi.java
import org.openapitools.client.model.Consumer;
import java.util.function.Consumer;
openapi-generator version
My project uses the latest release of the OpenAPI generator maven plugin:
<groupId>org.openapitools</groupId>
<artifactId>openapi-generator-maven-plugin</artifactId>
<version>5.2.0</version>
OpenAPI declaration file content or url
Found in the example project here
Generation Details
The client is generated using the maven plugin. See the pom.xml
Steps to reproduce
git clone git@github.com:Tomboyo/openapigen-bug-exmaple.git
cd openapigen-bug-exmaple
./mvnw clean compile
Related issues/PRs
I could not find any.
Suggest a fix
One approach is to use fully-qualified names for all types that otherwise rely on generated import statements. For each generated method, we would qualify the return type and parameter types. (Or, similarly, we could fully-qualify only the types used in the verbatim template.)
Bug Report Checklist
Description
I generated a client for a specification with a component called
Consumer. The generator produced a client with import statements for bothjava.util.function.Consumerand a...model.Consumer. As a result, the code cannot compile because thereference to Consumer is ambiguouswherever theConsumertype is referenced:openapi-generator version
My project uses the latest release of the OpenAPI generator maven plugin:
OpenAPI declaration file content or url
Found in the example project here
Generation Details
The client is generated using the maven plugin. See the pom.xml
Steps to reproduce
Related issues/PRs
I could not find any.
Suggest a fix
One approach is to use fully-qualified names for all types that otherwise rely on generated import statements. For each generated method, we would qualify the return type and parameter types. (Or, similarly, we could fully-qualify only the types used in the verbatim template.)