Kotlin Spring Generator: add type information to schema annotation

[rd-max-hartmann]

This PR fixes the problem that the open api generator does not set the type of the Schema annotation at all:
schema = Schema(type="integer", defaultValue = "0")

It's a problem, because we are using Open Api Code Generation in combination with Spring-Doc and Spring-Doc needs so type information of the schema to configure the Swagger UI correctly. Maybe other frameworks and tools rely also on it. This PR fixes only the kotlin-spring generator.

[wing328]

https://github.com/OpenAPITools/openapi-generator/actions/runs/18435804244/job/52531980060?pr=22109

please follow step 3 in the PR checklist to update the samples

cc @karismann (2019/03) @Zomzog (2019/04) @andrewemery (2019/10) @4brunu (2019/11) @yutaka0m (2020/03) @stefankoppier (2022/06) @e5l (2024/10)

[rd-max-hartmann]

https://github.com/OpenAPITools/openapi-generator/actions/runs/18435804244/job/52531980060?pr=22109

please follow step 3 in the PR checklist to update the samples

cc @karismann (2019/03) @Zomzog (2019/04) @andrewemery (2019/10) @4brunu (2019/11) @yutaka0m (2020/03) @stefankoppier (2022/06) @e5l (2024/10)

done

[Mattias-Sehlstedt]

Are you sure that @Parameter(schema = @Schema(type = "array", ...)) is the most proper representation and that it isn't that one should use @Parameter(array = @ArraySchema(schema = @Schema(...))) instead?

[rd-max-hartmann]

Are you sure that @Parameter(schema = @Schema(type = "array", ...)) is the most proper representation and that it isn't that one should use @Parameter(array = @ArraySchema(schema = @Schema(...))) instead?

@Mattias-Sehlstedt good point, but how can I implement this schema/array If-condition in the template?

[Mattias-Sehlstedt]

I believe It could for example be done if we were to place {{#isArray}} a little bit further out in the logic.

So lets say we have the current template with @Parameter(..., schema = @Schema(..., then we could break our schema = @Schema(... into its own template, and instead define something akin to @Parameter(..., {{#isArray}}array = @ArraySchema({{>schema_annotation}}){{/isArray}}{{^isArray}}{{>schema_annotation}}{{/isArray}})

Breaking out parts of the annotation creation into a separate mustache template would also go a long way in making it more readable, since now I find it quite hard to follow exactly what it does.

[rd-max-hartmann]

I believe It could for example be done if we were to place {{#isArray}} a little bit further out in the logic.

So lets say we have the current template with @Parameter(..., schema = @Schema(..., then we could break our schema = @Schema(... into its own template, and instead define something akin to @Parameter(..., {{#isArray}}array = @ArraySchema({{>schema_annotation}}){{/isArray}}{{^isArray}}{{>schema_annotation}}{{/isArray}})

Breaking out parts of the annotation creation into a separate mustache template would also go a long way in making it more readable, since now I find it quite hard to follow exactly what it does.

@Mattias-Sehlstedt it's too hard for me right now :-) I am not very familar with the template language. Could you please help me or is there a better way like creating an issue or a feature request?

[Mattias-Sehlstedt]

I can see if I can produce a solution.

I am a bit curious about the background. How come we have a specification, we generate a server definition for that, and then we use springdoc-openapi to introspect the generated server to get a specification, and then we expose that specification? How come we do not simply expose the initial specification used to generate the server?

Or do we have some controllers that are generated, and some that are not?

Edit: you can find a suggested solution here. Please try it out and see if it works for your use case.

[rd-max-hartmann]

I can see if I can produce a solution.

I am a bit curious about the background. How come we have a specification, we generate a server definition for that, and then we use springdoc-openapi to introspect the generated server to get a specification, and then we expose that specification? How come we do not simply expose the initial specification used to generate the server?

Or do we have some controllers that are generated, and some that are not?

@Mattias-Sehlstedt you are right, it's also possible to use the created spec directly in Swagger. Otherwise this setup comes from the OpenAPIGenerator that generates the SpringDocConfiguration. IMO the generated code is not correct and SpringDoc generates incorrect data-type mapping from it:

All these properties are boolean props in the spec