* 5705: Move JsonProperty annotation to the getters
* Regenerate samples
* Add jackson check
* Add test
* Minor fix
* Fix test
* Fix version
* [Java][Spring] update test & samples; add serialization/deserialization test
---------
Co-authored-by: Oleh Kurpiak <oleh.kurpiak@gmail.com>
* Added the useResponseEntity additional parameter for Spring generator
* Changed the mustache templates using the new useResponseEntity property
* Added the new property to the documentation
* Merging with remote master
* #11537 Added missing configuration for the delegate pattern case
* #11537 Added autogenerated @ResponseStatus on Spring methods
* #11537 Fixed borsch comments
* #11537 Added the default 200 HTTP Status for empty response HTTP code
* [Java][Spring] useResponseEntity sample + remove blank line
* [Java][Spring] useResponseEntity sample + remove blank line
* [Java][Spring] useResponseEntity sample + remove blank line
---------
Co-authored-by: Oleh Kurpiak <oleh.kurpiak@gmail.com>
* [PHP-Symfony] fixes validation of date-time parameter
This fixes parts of #14930.
Without this patch a parameter declared as date-time
is validated against Symfony's "DateTime" constraint,
which always fails. Because this constraint expects
a string with format "Y-m-d H:i:s".
It fails because the generated code performs the check
after the deserialization, so the variable checked is not
a string anymore.
Besides this, even if we performed that validation on the
string, that would not work well because OpenApi
specification expects date-time to conform to RFC 3339
and that "Y-m-d H:i:s" would reject RFC 3339 compliant dates.
With this change we ensure that the string provided by the
web user could be parsed by PHP to DateTime, which solves both issues.
(Note however that it means that it now accepts more formats than just
RFC 3339 compliant ones for those parameters (it would accept all formats
accepted by PHP DateTime). That being said it's compliant with the guideline
""be conservative in what you send, be liberal in what you accept")
* [PHP-Symfony] Fix handling of null date-time parameter
This fixes one of the issue described on #14930, namely that
the deserializeString method of the generated class JsmSerializer returns null
for other types of string, but not for date-time. Instead it returns a DateTime
which represents "now" (because that what `new DateTime(null)` does).
Consequently when an API declares a date-time parameter as non-required and
when that endpoint is called without that parameters, then the user code
would end up having "now" instead of "null" for this parameter.
Use a single InputStream instead of "File".
This allows the generated code to build in case of a definition like:
requestBody:
content:
text/plain:
schema:
type: string
format: binary
This fixes#9372
* Add constructor with required parameter for spring
Fix#9789
* [Java][Spring] constructor with required args
---------
Co-authored-by: Oleh Kurpiak <oleh.kurpiak@gmail.com>
* Fix serialization when there is a discriminator with mapping
* Update samples
* Update samples
* upgrade samples
* Revert "Update samples"
This reverts commit d6affde263d6c539e32a7f38dc984cf5948ab322.
* [Kotlin-Spring] Support multiline descriptions
This commit adds support for multiline descriptions for operations in
the Kotlin-Spring generator, for both regular API generation (i.e.
Controller), as well as interface-only API generation.
Multiline descriptions allow us to use rich text representations, e.g.
with Markdown. Note that Markdown-formatted descriptions are rendered
nicely in Swagger-UI. I imagine that most openapi consumers will be able
(or will want to) support Markdown (at some point).
The solution for Kotlin-Spring is rather simple, using Raw Strings to
contain the `unescapedNotes`.
See: https://kotlinlang.org/docs/strings.html#raw-strings
Note that specific unescaped strings could cause problems. For example,
the string containing three double quotes `"""` would result in compile
errors for the generated code. I think this is acceptable.
Note that an improvement is possible to use `.trimMargin()` in
combination with the pipe symbol `|`, to allow specific margin
prefixing.
Note that the description is used in escaped form in the JavaDoc. This
could be resolved by prefixing every line of the unescapedNotes with a
star `*`.
For now, I've chosen to implement this the simplest way I could think
off.
Signed-off-by: Nico Korthout <nico.korthout@camunda.com>
* [Kotlin-Spring] Update samples
Signed-off-by: Nico Korthout <nico.korthout@camunda.com>
---------
Signed-off-by: Nico Korthout <nico.korthout@camunda.com>
* [Kotlin] add spring boot 3 & jakarta extension support
* [kotlin-spring] readme update & modified imports
* use latest Spring Boot starter parent
* use same options as in [Java] generator
* new config kotlin-spring-boot-3
---------
Co-authored-by: jayandran sampath <jayandran.sampath@opencastsoftware.com>
* Added a Julia client and server
This PR adds two new generators for the [Julia language](https://julialang.org/)
- `julia-client` to generate a client from specifications
- `julia-server` to generate a server with stubs that can be used to host a server conforming to the specifications
The generated code uses the Julia [OpenAPI.jl](https://github.com/JuliaComputing/OpenAPI.jl) package that includes support functions for both client and server.
* fix javadoc generation
* add changes after ensure-up-to-date run
* Use correct Pascal case for java enum
* Uniquely name @Bean annotations
* Use existing mustache var instead, run generate files
* rebase, re-run generators
* try to undo botched rebase/merge
* Attempt to manually undo whatever is going on w/ build, oops
* Attempt to manually undo whatever is going on w/ build, oops