[JAVA] incorrect import mapping of alias types

[bkoziak]

[JAVA] incorrect import mapping of alias types

Description

Hi guys,

I've hit the wall trying to use importMapping together with type aliases. I'm a newbie when it comes to openapi so forgive me if I used wrong terms or something. Here's an example of what I wanted to achieve (use below yaml as a reference):

1. I've created TypeAlias which aliases string
2. I used TypeAlias as $ref for property typeAlias of ParentType schema
3. I configured openapi-generator-maven-plugin to map TypeAlias to foo.bar.TypeAlias
4. As a result typeAlias was generated as String instead of foo.bar.TypeAlias

openapi-generator version

master - 4.1.0-SNAPSHOT, 4.0.0, 3.x.x

OpenAPI declaration file content or url

openapi: 3.0.0
info:
  title: Sample API
  description: API description in Markdown.
  version: 1.0.0
paths:
  /type-alias:
    get:
      responses:
        200:
          description: OK
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ParentType'

components:
  schemas:
    ParentType:
      title: ParentType
      type: object
      properties:
        typeAlias:
          $ref: '#/components/schemas/TypeAlias'
    TypeAlias:
      type: string

Command line used for generation

Maven plugin with following importMapping configuration:

<importMappings>
    <importMapping>TypeAlias=foo.bar.TypeAlias</importMapping>
</importMappings>

Steps to reproduce

Related issues/PRs

Suggest a fix/enhancement

[pe-st]

Hello!

I have remarked the same problem and I could reproduce it with a unit test on a branch in my fork, using your OpenAPI document as input: https://github.com/pe-st/openapi-generator/tree/java-importmapping-3589

Unfortunately I don't know the code well enough to propose a fix...

• I've changed the type of TypeAlias from string to object
  (not sure if importMapping is supposed to work also for string types...)
• The generated ParentType.java references the TypeAlias type as Object
  and doesn't generate a TypeAlias.java, so the importMapping has some effect
• When generating the code with the 3.0.0 branch of swagger-codegen, TypeAlias
  is referenced as foo.bar.TypeAlias as expected...

[jmini]

This use case seems to be valid.

---

I am not saying that this is the definitive solution, but using the generateAliasAsModel flag might help. The idea behind this flag was to preserve the Swagger-Codegen behavior when generating list of items:

  schemas:
    User:
      type: object
      properties:
        addresses:
          $ref: '#/components/schemas/Addresses'
    Addresses:
      type: array
      items:
        $ref: '#/components/schemas/Address'
    Address:
      type: object
      properties:
        firstLine:
          type: string
        secondLine:
          type: string
        city:
          type: string
        zipCode:
          type: string

Swagger-Codegen generate in this case Addresses extends List<Address> but having type-alias for collections is not really what you want in java (you can not use all java API such as stream-collect or List.of(..)).

---

I think that even without generateAliasAsModel, if you provide the type-alias from the outside then this definition should be used in the generated code.

[pe-st]

Setting generateAliasAsModel to either true or false makes no difference, TypeAliasis still referenced as Object in the generated POJO.

What do you mean by provide the type-alias from the outside ? I played around with languageSpecificPrimitives and typeMappings (as suggested in https://openapi-generator.tech/docs/usage#type-mappings-and-import-mappings), but that didn't help either.

[bkoziak]

If you're still interested I've prepared a fix in my forked repo but haven't had time to make a PR and merge it back to main repo. I did it a few months ago, so merge will be probably required to make it working again.
Hope it will help you https://github.com/bkoziak/openapi-generator/tree/import-mapping-with-type-aliases-issue-3589

[pe-st]

Thanks @bkoziak ! I just submitted the PR based on your work

[wing328]

The PR has been merged. Thanks both for contributing the enhancement.