Fix map parameter not a container

[Kahncode]

Map parameters now carry their container properties when generated from map properties. This solves an issue where a map parameter was not considered a container and induced generation errors.

DISCLAIMER: This is a change that may impact other generators in unexpected ways. However the code when I read it did not feel correct, as the case of map as parameter is simply not handled. It's a bit obscure to me what should and what should not be carried over from CodegenProperty into CodegenParameter but my assumption was that most things should be, especially the "isContainer" property which solves the bug i'm chasing. I've tried my best to keep it generic and logical but I think this needs a better pair of eyes from one of the core maintainers of the project.

Out of curiosity, why aren't most things carried over? For example isPrimitiveType is set explicily in the if/else cases rather than simply copied from the property. At least, from a generator template developer's perspective, having the parameters and property as similar as possible and having the same fields makes working on the mustache files that much easier. This bug was a good example of a case where the behavior was not expected as isContainer always worked for properties but in this case didn't for parameters.

I can provide an openapi spec that exhibits the issue upon request, the issue was observed using the cpp-ue4 generator. It is hard for me to test against other generators, but this should not be a neutral change. My development environment has always been incomplete and as such I am not able to easily regenerate the samples, but I do expect some changes in some of the generators.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh ./bin/configs/*.yaml
  ./bin/utils/export_docs_generators.sh
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.1.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@wing328

[wing328]

thanks for the fix. can you please add a test or 2 in default codegen test?

[wing328]

Out of curiosity, why aren't most things carried over? For example isPrimitiveType is set explicily in the if/else cases rather than simply copied from the property.

If I remember correctly, this could be the "historical" reason before even I started working on this project.

[wing328]

cc @OpenAPITools/generator-core-team

[wing328]

My development environment has always been incomplete and as such I am not able to easily regenerate the samples, but I do expect some changes in some of the generators.

no change in samples because we didn't test map parameters in the test spec at the moment.

can you add one to cpp-ue4 petstore samples?

$ cat ./bin/configs/cpp-ue4.yaml
generatorName: cpp-ue4
outputDir: samples/client/petstore/cpp-ue4
inputSpec: modules/openapi-generator/src/test/resources/2_0/petstore.yaml
templateDir: modules/openapi-generator/src/main/resources/cpp-ue4

first copy modules/openapi-generator/src/test/resources/2_0/petstore.yaml to modules/openapi-generator/src/test/resources/3_0/cpp-ue4/petstore.yaml

(note that we use 3.0 spec here)

and then add a fake endpoint to modules/openapi-generator/src/test/resources/3_0/cpp-ue4/petstore.yaml, e.g. https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/test/resources/3_0/petstore-with-fake-endpoints-models-for-testing.yaml#L1089

then compile the output locally to ensure it's good.

[Kahncode]

Will do, I have indeed tested this for my generator and it compiles fine, but i'm worried about the impact on others, although technically this was never well supported.

[Kahncode]

@wing328 Added the test file, seems to generate correctly.

[wing328]

lgtm. let's give it a try