openapi-generator: [BUG][openapi-generator-maven-plugin] importmapping not respected since 5.4.0

Bug Report Checklist

Have you provided a full/minimal spec to reproduce the issue? Yes, inside attached ZIP
Have you validated the input using an OpenAPI validator (example)?
Have you tested with the latest master to confirm the issue still exists? -> No, but tested with 5.4.0
Have you searched for related issues/PRs?
What’s the actual output vs expected output? Expected: StreamingResponseBody, Actual: Stream
[Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

The “importMappings” seem to have no effect with version 5.4.0. With version 5.3.1 the below configuration resulted in a “StreamingResponseBody” in the generated class. With version 5.4.0 a “Stream” class is imported but that one does not exist.

openapi-generator version

Issue occurs with openapi-generator-maven-plugin 5.4.0 and did not occur with the previous version 5.3.1.

OpenAPI declaration file content or url

If you post the code inline, please wrap it with

openapi: 3.0.3
info:
  title: Demo app
  version: 1.0.0
servers:
  - url: /api/v1
paths:
  /demo:
    get:
      summary: Demo
      operationId: demo
      responses:
        '200':
          description: Demo response
          content:
            text/csv:
              schema:
                type: string
                format: binary

Generation Details

Plugin configuration:

      <plugin>
        <groupId>org.openapitools</groupId>
        <artifactId>openapi-generator-maven-plugin</artifactId>
        <!-- With version 5.3.1 of the plugin, the generated "DemoApi.java" contains default org.springframework.web.servlet.mvc.method.annotation.StreamingResponseBody as expected -->
        <!-- With version 5.4.0 of the plugin, the generated "DemoApi.java" contains "Stream", but the org.example.bug.demo.api.Stream is not created -->
        <version>5.4.0</version>
        <executions>
          <execution>
            <id>bug-demo</id>
            <goals>
              <goal>generate</goal>
            </goals>
            <configuration>
              <inputSpec>${project.basedir}/src/main/resources/spec.yaml</inputSpec>
              <generatorName>spring</generatorName>
              <apiPackage>org.example.bug.demo.api</apiPackage>
              <modelPackage>org.example.bug.demo.api</modelPackage>
              <configOptions>
                <delegatePattern>true</delegatePattern>
              </configOptions>
              <importMappings>
                stream=org.springframework.web.servlet.mvc.method.annotation.StreamingResponseBody
              </importMappings>
              <typeMappings>string+binary=stream</typeMappings>
            </configuration>
          </execution>
        </executions>
      </plugin>

Steps to reproduce

Run mvn clean install on the attached demo project.

Related issues/PRs

No similar issues.

Suggest a fix

Not sure what causes the problems, but I assume it has to do with this change: https://github.com/OpenAPITools/openapi-generator/pull/11217

bug Demo application

bug-demo.zip

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 6
Comments: 27 (13 by maintainers)

Links to this issue

swagger - Use java.time.Instant to represent DateTime instead of OffsetDateTime - Stack Overflow

Commits related to this issue

various experiments This is to investigate https://github.com/OpenAPITools/openapi-generator/issues/14525 and https://github.com/OpenAPITools/openapi-generator/issues/11506. — committed to martin-mfg/openapi-generator by martin-mfg a year ago

Most upvoted comments

Same, but for the gradle plugin

sigand on Feb 16, 2022

Same here

clemjt on Feb 21, 2022

@IncPlusPlus I tried to use typeMappings instead of importMappings since from the documentation it is not immediately clear what the difference is.

It seems like the typeMappingDateTime= java.time.ZonedDateTime will perform a substitution of all occurrences of DateTime with java.time.ZonedDateTime in the api specification. In your case java.time.ZonedDateTime is not a valid identifier so it will be transformed to something like JavatimeZonedDateTime. It seems like that option is used to solve an entirely different problem.

What I am looking for is a way to skip codegen for some models and just use an import/fqn instead. Before 5.4.0 that could be done with importMappings.

exaV on May 23, 2022

@jorgerod sorry could you provide a little snip of code to clarify the case?

Thanks, S.

foxpluto on Jul 22, 2022

I previously used importMapping to be able to use Java’s ZonedDateTime type for the OpenAPI date-time string format. By default, the field would be a java.time.OffsetDateTime. The configuration used to look like this (I’m using Gradle):

configOptions = [
  'dateLibrary': 'custom',
]
typeMappings = [
    'DateTime': 'ZonedDateTime',
]
importMappings = [
    'ZonedDateTime': 'java.time.ZonedDateTime'
]

With that configuration, the fields would be declared in the generated file with the fully qualified java.time.ZonedDateTime type. Since 5.4.0, the generated field is now of type “ZonedDateTimeDto” and there’s an import statement at the top of the file now as if it’s expecting there to be a DTO with that name.

My current workaround is by removing importMappings entirely and doing the following:

configOptions = [
  'dateLibrary': 'custom',
]
typeMappings = [
  'DateTime': 'java.time.ZonedDateTime',
]

Looking at the Gradle plugin’s configuration options, it seems like using only typeMappings should be fine for me as a long-term solution. I guess the only reason I previously needed importMappings was if I didn’t want to specify the whole package name in the typeMappings section.

IncPlusPlus on May 21, 2022

The following configuration works for us:

<configuration>
    <!-- some other configurations -->
    <schemaMappings>External=org.my.other.depnendecy.ExternalDto</schemaMappings>
 </configuration>

gong4soft on Nov 16, 2022

Hi We have the same problem. For us, this feature is very important. Is there any workaround or other way to do it?

In case of a fix for this bug, would it be released in a 5.4.x version?

@wing328 @bbdouglas @sreeshas @jfiala @lukoyanov @cbornet @jeff9finger @karismann @Zomzog @lwlee2608

Thank you very much

jorgerod on Feb 25, 2022