This is an intermediary work around for issues such as #3456. This fixes #5920 (closed).
There's still an issue with applying the import of HashMap when referencing a map-like type. For an example of the issue, generate with the new mapSchemas.yaml test file and inspect the FreeformObjectTypes
type.
Applying container import logic similar to what's done in DefaultCodegen:
// TODO revise the logic to include map
if (cp.isContainer) {
addImport(m, typeMapping.get("array"));
}
for map does not work as expected because Java defines the type mapping as java.util.Map
and the instantiation type as java.util.HashMap
. It seems like the above snippet in DefaultCodegen might need to account for both the type mapping and the instantiation type when modifying a model's imports.
PR checklist
-
Read the contribution guidelines. -
If contributing template-only or documentation-only changes which will change sample output, build the project before. -
Run the shell script(s) under ./bin/
(or Windows batch scripts under.\bin\windows
) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run./bin/{LANG}-petstore.sh
,./bin/openapi3/{LANG}-petstore.sh
if updating the code or mustache templates for a language ({LANG}
) (e.g. php, ruby, python, etc). -
File the PR against the correct branch: master
,4.3.x
,5.0.x
. Default:master
. -
Copy the technical committee to review the pull request if your PR is targeting a particular programming language.