* remove legacy laravel generator
* initial setup of my vision for the laravel generator
* update the php laravel samples
* update php laravel docs
* moved api validation into controller and handle edge cases presented by sample generation
* updated samples
* added php-laravel to github workflow php8 and removed php7 workflow as it only contained old laravel
* preemptive work to support union types as soon as php serde supports them
* updated samples
* update templates in accordance to samples output
* fix pipelines and update samples
* correct serde version
* fixed phpunit execution and updated samples
* added named routes
* remove
* readd samples
---------
Co-authored-by: gijs.blanken@futureof.finance <gijs.blanken@finly.nl>
Co-authored-by: William Cheng <wing328hk@gmail.com>
* [rust] Added support for text/plain to reqwest-trait client
* Updated samples
* [rust] Added support for text/plain to reqwest client
* Updated samples
* cleanup
* reduced compiler warnings
* fixed text/plain content with charset
* Only deserialize text/plain if the API produces it
* [JavaSpring] attach sources when using maven and interfaceOnly=true
Closes#15659
* [kotlin-spring] attach sources when using maven and interfaceOnly=true
Closes#15659
The change in #20067 has caused some issues with clients which run in a
Browser. This commit replaces that change, leaving the default
User-Agent for axios unmodified, and only sets the User-Agent if the
`http-user-agent` parameter is provided during generation time.
- Fix enum default value generation. Default values were falling back to the default code generator and were being generated improperly for Julia.
- Add more validations to client and server API call handlers. These validations were already being generated for models, but were missed out for API calls.
* move validator import into GoClientCodegen
* add new example for oneof discriminator lookup
* regenerate samples
* add validator.v2 to go.mod if it is imported
* regenerate samples
* Fix enum discriminator default value
* Remove system out call
* Add case when discriminator type is ref
* Use correct schema
* Handle different use cases of mappings
* Add missing enum type Lizzy
* Make it more robust
* Add missing test for Sedan
* Refactor some code to make it cleaner
* Initialize discriminator enum field
* Don't override existing default value
* Fix issue with finding discriminators
* Move setIsEnum back to its original location
* Be smarter about figuring out the model name
* Fix final warnings
* Add javadocs to introduced methods
* [C][Client] Generate CMakeLists.txt for all C sample clients
The sample client defined in bin/configs/c.yaml has CMakeLists.txt in
its .openapi-generator-ignore. It's is the only C client that doesn't
(re-)generate CMakeLists.txt, the remaining two seem fine regardless.
* [C][Client] Allow user-defined CMAKE_C_FLAGS
* [C][Client] Remove useless message() calls from CMakeLists.txt
find_package() prints success/failure messages, no need to do it twice.
* prevent all name clashes by using a prefix for all parameters, this way they CANNOT clash with anything locally, as our hardcoded stuff in mustache files doesnt start with "p_" ,
when using the grouped option, we just use the params directly and dont unpack the variables at all, prevending furthur name clashes.
* get rid of "local_var" prefix, now that we no longer clash with paramater names
* fix a typo and remove the r# generated to the paramName when we create the identifier
* java code formatting and added a fake-endpoint parameter test
* update rust samples
* Fix Julia template for binary format
* Update julia samples
* fix missing check for the isBinary flag
Fix missing check for the isBinary flag in some places of the templates for julialang. The code would now be generated as Vector{UInt8} uniformly for binary strings. Binary strings that are also marked as files get generated as `String` data type on the client. That is because the Julia client expects a file name to be passed there.
* Fix Julia template for file
* Update julia samples
---------
Co-authored-by: tan <tanmaykm@gmail.com>
* Adds @Nullable annotation to Spring Boot generator
* issue-14427: [REQ][spring] Null-Safety annotations
* issue-17382: [REQ] spring generator add Nullable annotations
Motivations:
* Have Spring Boot generator client properly annotated for nullability to be able to check code using them with tools like NullAway
* As it is related to Spring then the `org.springframework.lang.Nullable` annotation was chosen to avoid discussion which `@Nullable` one is true one
* `@NonNull` wasn't used as I didn't see much benefit of it. Anyhow, an empty constructor and/or setters allow to put a `null` value there
Modifications:
* Adds nullableAnnotation template to handle nullability annotation on vars
* Adjust pojo templates to use the nullability template
* Adapts tests
Modifications:
* Runs export_docs_generator.sh script to update samples
* samples update
* excludes Spring @Nullable from java-camel
* ones with defaults shouldn't be annotated as @Nullable
* updates samples
* adds AllArgConstructor generation tests
* adds container tests
* [C] Deprecate *_create() to avoid *_free() confusion
The behaviour of *_free() doesn't match *_create(), so the user should
avoid using them together. But they still need *_free() to clean up
library-allocated objects, so add a _library_owned flag to each struct
as an attempt to tell them apart. This isn't perfect though, because the
user may neglect to zero the field, but they would still see a warning
once in a while so it serves its purpose.
To prevent the new deprecation warnings (intended for the user) from
showing up during the library build itself, define a new family of
*_create_internal() functions, and turn *_create() into simple wrappers.
* Update samples
* add eafer to c technical committee
---------
Co-authored-by: William Cheng <wing328hk@gmail.com>
