Open daiscog opened 4 years ago
@daiscog I ran into this as well. I've found that using the lowercase file
name for the schema in your api.yaml
results in the class being generated. Then you can set the import mapping as you identified for a full workaround.
This behavior has been in the generator for a very long time, from what I can tell, so it may be one of those bugs that breaks things when it gets fixed. It seems that somebody made a design decision to map File
schemas to java.io.File
, so I hesitate to open a PR that undoes that decision without understanding the original justification.
This also affects the spring
generator.
File
, it will use java.io.File
.file
, it will use org.springframework.core.io.Resource
.I just stumbled upon this behavior in the kotlin
generator. This can be quite confusing since the Kotlin compiler initially reports ambiguous/invalid FQN usages where other JDK classes like java.net.URI
are used, so at first glance I suspected some sort of JDK/buildscript issue.
My workaround was to use an import mapping from File
to File
(so the class is generated as File.kt
), and then use a manual post-processing step via Gradle's doLast
and fileTree
to remove the resulting invalid import File
directives in all generated files.
another way is to use the modelNameMappings option to rename the schema "File" to something else (e.g. ModelFile)
ref: https://github.com/openapitools/openapi-generator/blob/master/docs/customization.md#name-mapping
@wing328 Thanks for the pointer! I thought I already had tried all kinds of mappings, but that is indeed much easier.
When an api.yml file contains a type definition called 'File' no model class is generated by the Java/spring generator for that type.
openapi-generator version
4.2.2
Details
The
api.yaml
file defines a type calledFile
and an endpoint that returns a wrapper object containing a field of this type.The generator is configured to use the package
com.example.rest.model
for generated model classes.Expected behaviour:
com.example.rest.model.File
should be generatedcom.example.rest.model.FileWrapper
should contain a field calledfile
of typecom.example.rest.model.File
Actual behaviour:
com.example.rest.model.File
is generatedfiles
field of the generated wrapper class is of typejava.io.File
Partial workaround:
The second issue (incorrect import type) can be worked around by explicitly adding the import-mapping
File=com.example.rest.model.File
to the configuration.However, the class
com.example.rest.model.File
is still not generated.Steps to reproduce
To reproduce, extract the attached oas-generator-file-bug.tar.gz file
cd
into the extracted project dir and runmvn clean generate-sources
Alternatively, the api.yaml file and a pom.xml configured to use the generator maven plugin can be seen here: https://gist.github.com/daiscog/71908355396370a6a4316d0adfeb6d31