Open chrylis opened 5 years ago
After noticing something else, I tried removing the language-specific primitive that was suggested in docs; the import mapping is the controlling variable and is both necessary and sufficient for this use case (although apparently having a completely flat namespace for the $ref
types is a little concerning).
You may also want to try the latest master (the snapshot version can be found in the README)
With 4.0.0.beta3, this substitution fails in both cases. In the case of type: string
, the Java type is java.lang.String
, and with type: object
, it is java.lang.Object
.
This bug is still present in 4.2.1. Specifically, it presents when either the custom type is of type: string
(think something like a UUID) or when the custom type is of type: object
but does not have properties defined. Only when the custom type has at least one property is the import mapping respected.
What about using something like the following instead?
EntityIdentifier:
type: string
format: EntityIdentifier
I remember it works for type mapping but not sure about import mapping. Please give it a try.
Description
I am trying to map a custom data type to a JSON string-valued property (more or less equivalent to a custom format); Jackson will transparently handle the conversion for me in Java. However, the generator does not observe user custom mappings when a
$ref
type is marked as a string.openapi-generator version
This behavior is observed with 3.3.4
OpenAPI content
Command line used for generation
Invoked via Maven plugin:
Steps to reproduce
As above, a
$ref
that is oftype: string
does not get overridden by the custom mapping.