This adds some conistency to how validation properties are persisted to
the Codegen* types. Whenever we extract metadata from an OpenAPI Schema,
that metadata may include properties defined in the JSON Schema
Validation specification section 6 (see
https://json-schema.org/draft/2019-09/json-schema-validation.html#rfc.section.6).
Previously, only some of these were copied.
This creates an interface allowing for consistent type access across:
* CodegenModel
* CodegenParameter
* CodegenProperty
* CodegenResponse
This does _not_ change existing public fields which previously exposed
these on some of the above type (see CodegenParameter).
CodegenModel has a legacy edge case where primitive types could be
represented at that level rather than as a referenced schema. This adds
the sync of validation properties to these primitive constructs for
CodegenModel with a note that they're legacy and likely to be removed
later.
* [Slim4] Add OpenApiDataMocker interface template
* [Slim4] Implement scalar types in data mocker
* [Slim4] Cleanup, remove unused variables
I've rejected the idea to keep Composer dependencies in Java/codegen
variables at some point of time. It seems that after Git rebase I forgot
to delete them.
* [Slim4] Refresh samples
* [Slim4] Add pattern option to mockString method
[ref] https://tools.ietf.org/html/draft-wright-json-schema-validation-00#section-5.8
* [Slim4] Add enum option to mockString method
[ref] https://tools.ietf.org/html/draft-wright-json-schema-validation-00#section-5.20
* [Slim4] Refactor mockInteger and mockNumber tests
* [Slim4] Refactor mockString tests
* [Slim4] Use null coalescing operator
* [Slim4] Implement enum option in mockString method
* [Slim4] Add tests for enum option of mockString
* run all script in circleci
* test kotlin clients
* add new files
* undo chanages to circleci script
* update samples
* update bitwise config
* fix typo
* Some clean code.
* Add support for retrofit2 in models and apis. Need work in ApiClient, but it's not urgent.
* Add ApiClient with retrofit2 support.
* Remove unnecessary package.
* Add scripts to generate samples.
* Generate sample of retrofit2
* Change toUpperCase to toUpperCase(Locale.ROOT) to fix compile.
* Added GSON library when it's needed
* Fix typo.
* Add some missing common files.
* Execute bin script.
* Remove copy&paste error in script.
* [kotlin] update outdated files
* Fix apis with no params.
* Add missing import in ApiClient
* Add support for CSV, SSV, TSV, PIPES, SPACES in retrofit 2 library.
* Fix package name.
* Execute kotlin-client-retrofit2.sh script.
* force rebuild.
* execute script again.
* Add missing imports from okhttp3.
@Deprecated has a message param that java not. Add it with a default message.
* Execute retrofit2 script.
* Rerun script.
* Adds composed model support for allOf oneOf anyOf
* Moves discriminator into discriminator() class method, adds test_deserialize_lizard, adds setting discriminator using allOf schema
* [typescript-angular] Control response mime type via param
* [typescript-angular] Update samples.
* [typescript-angular] Wrap httpHeaderAccept in an options object.
* [typescript-angular] Updated samples.
* Fix multi-part binary array strings
Multi-part binary array strings as outlined in #3139 resulted in `MultipartFile` rather than `List<MultipartFile>`. This PR attempts to resolve this by adjusting the templates.
Two tests have been added: one for `spring-boot` and one for `spring-cloud`.
Resolve#3139
* Fix multipart file name and description
* Handle array of MultipartFile for delegate
* Update samples due to file description being picked up
* Upload result of bin/spring-stubs
OAS 3.x specification isn't entirely clear on oneOf support. JSON Schema
defines oneOf in such a way that the Schema is only valid if it
validates against exactly one of the referenced Schemas. This suggests
that a Schema defined with oneOf can't include additional "dynamic"
properties. OpenAPI extends on this by adding the necessary
discriminator object, which allows tooling to decide the intended
Schema.
As tooling, openapi-generator may support loose or confusing definitions
in the Specification to better support our user's use cases. In this
case, we may warn that while this usage is technically valid the two
target specifications are unclear about the actual constraints regarding
oneOf.
