[core] cleanup: remove OpenAPI parameter from CodegenConfig methods

[jmini]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language. @OpenAPITools/generator-core-team

Description of the PR

In order to solve #1927 I will need to access the OpenAPI instance in DefaultCodegen#toDefaultValue(..) in order to be able to see if the schema contains a $ref and if this is the case, to see if the referenced schema has a default value or not.

The main change of this PR is to have:

• public String toDefaultValue(Schema p, OpenAPI openAPI)
• Instead of public String toDefaultValue(Schema p)

To fulfill this requirement the OpenAPI is added as parameter to some methods of DefaultCodegen.

Some of those methods also had Map<String, Schema> allDefinitions which corresponds to openAPI.getComponents().getSchemas(). This parameter was also removed from the methods, and the openAPI instance is used to access to all schemas.

Based on feedback the initial intention of this PR was changed.

Historically, to access the OpenAPI instance, or all schemas of the OpenAPI instance, parameters were used in different methods. Example:

• CodegenConfig#fromOperation(String, String, Operation, Map<String, Schema>, OpenAPI)
• CodegenConfig#fromModel(String, Schema, Map<String, Schema>)
• DefaultCodegen#fromResponse(OpenAPI, String, ApiResponse)
• DefaultCodegen#DefaultCodegen.fromRequestBody(RequestBody, Map<String, Schema>, Set<String>, String)
• DefaultCodegen#createDiscriminator(String, Schema, Map<String, Schema>)
• ...

Then @wing328 noticed that access to this information is requested in a lot of places (for unaliasing).
So he introduced a new approach: having two members globalOpenAPI and globalSchemas.

Having two ways for doing the same task is not consistent. It is harder to understand, to maintain and can lead to errors (for example all the unit tests were not using globalOpenAPI, meaning that they were not reproducing real cases, because when the generator is used for real, then the globalOpenAPI member is set).

This PR cleans the situation by removing the original approach completely. There is no openAPI or allDefinitions parameter anymore in the methods. Instead they use the globalOpenAPI member which is renamed openAPI.

In addition globalSchemas was only a convenient and null-pointer safe access to openAPI.getComponents().getSchemas(). It is also removed.

This change is mentioned in the migration guide "From 3.x to 4.0.0"

In my opinion the PR improves the readability of the code and reduces the potential coding mistakes.

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[jmini]

Input @wing328

have you considered using

openapi-generator/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java

Lines 143 to 144 in 2e3d04c

	protected OpenAPI globalOpenAPI;
	protected Map<String, Schema> globalSchemas;

?

This is a very good feedback.

After a short discussion on Gitter we agreed that:

• We will rename this.globalOpenAPI to this.openAPI (and the setter accordingly)
• We will use only this way to access to the openAPI instance, meaning that all methods fromModel(..), fromRequestBody(..) will no longer have openAPI has parameter.

This way we are consistent and have only one pattern in place.

[jmini]

PR is updated with new commits.
Description of the PR was changed to reflect the new intention.
WIP Tag is removed.