We've encountered an issue when using openapi-generator with an OpenAPI specification that utilizes exclusiveMinimum for number properties. Specifically, the syntax for exclusiveMinimum differs between OpenAPI Specification 3.0.0 and 3.1.0, and openapi-generator currently only seems to support the 3.0.0 syntax.
In our file, for a property like PriceDTO.originalPrice, we need to define exclusiveMinimum.
OpenAPI 3.0.0 syntax for exclusiveMinimum:
type: number
exclusiveMinimum: true
minimum: 0
OpenAPI 3.1.0 syntax for exclusiveMinimum (as per specification):
type: number
exclusiveMinimum: 0
When our openapi.yaml uses the 3.1.0 style for exclusiveMinimum, openapi-generator fails to correctly process the schema, leading to generation errors or incorrect model definitions.
We would like to inquire if there are plans to update openapi-generator to fully support the OpenAPI 3.1.0 syntax for exclusiveMinimum, or if there's a recommended workaround for this compatibility issue.
This issue impacts our ability to seamlessly upgrade our OpenAPI specifications to 3.1.0 while continuing to use openapi-generator for client/server code generation.
We've encountered an issue when using
openapi-generatorwith an OpenAPI specification that utilizesexclusiveMinimumfor number properties. Specifically, the syntax forexclusiveMinimumdiffers between OpenAPI Specification 3.0.0 and 3.1.0, andopenapi-generatorcurrently only seems to support the 3.0.0 syntax.In our file, for a property like
PriceDTO.originalPrice, we need to defineexclusiveMinimum.OpenAPI 3.0.0 syntax for
exclusiveMinimum:OpenAPI 3.1.0 syntax for
exclusiveMinimum(as per specification):When our
openapi.yamluses the 3.1.0 style forexclusiveMinimum,openapi-generatorfails to correctly process the schema, leading to generation errors or incorrect model definitions.We would like to inquire if there are plans to update
openapi-generatorto fully support the OpenAPI 3.1.0 syntax forexclusiveMinimum, or if there's a recommended workaround for this compatibility issue.This issue impacts our ability to seamlessly upgrade our OpenAPI specifications to 3.1.0 while continuing to use
openapi-generatorfor client/server code generation.