Generation of spec of two identically named classes in different packages yields spec with one entity

[drvdijk]

Expected Behavior

When generating specs for applications that have identically named but different classes in different packages, the resulting spec should include both entities in the schemas section of the spec.

I expect the spec to look something like this:

openapi: 3.0.1
info:
  title: swagger-server
  description: Example
  version: "1.0"
paths:
  /api/example/a:
    get:
      operationId: entity
      responses:
        "200":
          description: entity 200 response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Entity'
  /api/example/b:
    get:
      operationId: entity_1
      responses:
        "200":
          description: entity_1 200 response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Entity_1'
components:
  schemas:
    Entity:
      required:
      - fieldA
      type: object
      properties:
        fieldA:
          type: string
    Entity_1:
      required:
      - fieldB
      type: object
      properties:
        fieldB:
          type: string

Actual Behaviour

The resulting spec only has the entity (note the operationId of the spec is correct, even though the method names in the controllers are equal too):

openapi: 3.0.1
info:
  title: swagger-server
  description: Example
  version: "1.0"
paths:
  /api/example/a:
    get:
      operationId: entity
      responses:
        "200":
          description: entity 200 response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Entity'
  /api/example/b:
    get:
      operationId: entity_1
      responses:
        "200":
          description: entity_1 200 response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Entity'
components:
  schemas:
    Entity:
      required:
      - fieldB
      type: object
      properties:
        fieldB:
          type: string

Steps To Reproduce

1. clone sample repo
2. mvn compile
3. observe generated spec in target folder

Environment Information

We ran acros this where a local machine would yield a spec with fieldA in it, and a cloud based CI/CD pipeline would end up with a spec with fieldB in it.

Local:

• Mac M1, MacOS Ventura 13.2.1
• OpenJDK 11.0.17
• Maven 3.8.6
• Micronaut 3.8.6
• Micronaut OpenAPI 4.8.4

Cloud CI/CD

• Bitbucket pipeline
• Docker image maven:3.8.4-jdk-11
• Micronaut 3.8.6
• Micronaut OpenAPI 4.8.4

Example Application

https://github.com/drvdijk/micronaut-openapi-bug

Version

3.8.6