String/Boolean map using additionalProperties is not generated

[JFCote]

Description

I have a simple object declared like this:

StringBooleanMap:
      additionalProperties:
          type: boolean

It was used in another model:

  GetFrontEndPermissionsResponse:
    type: object
    required:
      - meta
    properties:
      meta:
        $ref: "#/definitions/ResponseMeta"
      data:
        $ref: "#/definitions/StringBooleanMap"

With swagger-codegen, it was simply generated and used in the models needing it. It was looking like that when used in a model:

@JsonProperty("data")
  private StringBooleanMap data = null;

With openapi-generator, it is not generated at all. Instead, it simply generate a "map" with no type.

@JsonProperty("data")
  private Map data = null;

This is a very bad regression since we cannot validate that the map really is a String/Boolean, we lose type safety.

openapi-generator version

Latest master

Command line used for generation

java -jar openapi-generator-cli.jar generate -i swagger.yaml --generator-name java-play-framework -o generatedServer -DhideGenerationTimestamp=true

Steps to reproduce

Just run the above command line and make sure you have and object using the StringBooleanMap object in one of its property.

Related issues/PRs

I think it is related to #185

Suggest a fix/enhancement

I think if we don't want to lose all the current swagger-codegen users that would want to switch, we need to generate stuff that was previously generated and it just make sense. If I create a model and that this model is referenced somewhere else, we should generate it "as is". Converting it to "basic type" is a very dangerous assumption that do not follow the spec in my opinion. And as I said earlier, this break type safety when dealing with collection (Map in this case)

[jmini]

A lot has changed in the OpenAPI instance (model classes defined in swagger-core) we get when we parse a spec. This is why we needed to change stuff in the code that interprets the model and prepare the objects that will be used in templates.

Reporting cases like this one is exactly the way we can improve the quality of OpenAPI-Generator. It has a simple minimal example. Some information to understand the context. This is perfect. Thank you a lot!

I hope we will get those issue fixed for 3.0.1 or 3.0.2 in order for you to be able to migrate from swagger-codegen v2 to OpenAPI-Generator.

[JFCote]

@jmini Thanks. Will keep a look at these issue and will gladly test the PR when available.

[wing328]

@JFCote I'll have a look at this one and #255 tomorrow (Wed)

[wing328]

@JFCote I've filed #360 to fix the issue. Please give it a try when you've time.

[JFCote]

@wing328 I could not do a full test with my complete spec because there are still 3-4 others things that don't compile related to other issues but it looked like your changes are working. If later I find something else, I'll open a new bug. I'm trying to figure out how to use openapi-generator instead of swagger-codegen but the amount of change and things that doesn't work is overwhelming (at least with my spec and my current code). I will try to find some time in the upcoming days to validate other fixes and to sort this out :)