* feat: add support for Swagger v3 annotations to jaxrs-spec
* test added unittest for jaxrs-spec with swagger3Annotations
* test added integrationtest for jaxrs-spec with swagger3Annotations
* test added integrationtest for jaxrs-spec with swaggerV2Annotations
* documentation update for new option useSwaggerV3Annotations in the jaxrs-spec.md
* test added integrationtest for jaxrs-spec with swaggerV3Annotations icm use JakartaEE
* update documentation by executing: ./bin/utils/export_docs_generators.sh
* ran on wsl: ./bin/generate-samples.sh ./bin/configs/*.yaml
* fix(c): Remove duplicate code generation for UUID path parameters
The C generator was generating duplicate path parameter handling code
when a parameter had format: uuid. This occurred because UUID parameters
have both isString=true and isUuid=true flags set, causing both the
{{#isString}} and {{#isUuid}} template blocks to execute.
The duplicate {{#isUuid}} block has been removed since it generated
identical code to the {{#isString}} block. This makes UUID parameters
consistent with email parameters, which already work this way
(isEmail=true and isString=true, but only use the {{#isString}} block).
The generated code now compiles successfully without duplicate variable
declarations.
* test(c): Add UUID path parameter test case to petstore
Adds endpoint with UUID path parameter to verify C generator produces compilable code without duplicate variable declarations.
* chore(samples): Regenerate all C samples with template fix
Regenerated all C sample variants to include the UUID path parameter example.
The Ruby code that is generated copies numerous methods into every
model. This creates bloat both in file size and run-time memory usage.
This commit introduces a base class for all models to store common
methods. This commit's focus is only on static methods that do not
change between models.
* Expose mtls config params in python template
* Expose certFile and keyFile configuration items to support mtls in php generated client
* Regenerate of examples
* [Julia] Fix docstring parameter formatting with backticks
Wrap parameter names in backticks in generated Julia client docstrings
to prevent markdown from misinterpreting underscores as italic formatting.
This fixes an issue where parameter names like `pet_id`, `api_key`, and
`additional_metadata` would render incorrectly in documentation, with
underscores being treated as markdown italic markers instead of literal
characters.
Related issue: JuliaComputing/OpenAPI.jl#72
* Also wrap data types and return types in backticks
* Regenerate Julia client samples with backticked docstrings
* [Julia] Add backticks to all markdown documentation templates
Extend backtick formatting to markdown documentation templates for
both Julia client and server generators. This ensures consistent
markdown rendering of identifiers with underscores.
Changes:
- julia-client/api_doc.mustache: Add backticks to function signatures,
parameter names, types, and return types in markdown API docs
- julia-server/api_doc.mustache: Same changes for server API docs
- julia-client/model_doc.mustache: Add backticks to property names and
types in markdown model documentation
- julia-server/model_doc.mustache: Same changes for server model docs
All generated markdown files now properly display identifiers like
`pet_id`, `Custom_Type`, `update_pet_with_form` with literal
underscores instead of broken italic formatting.
Related to JuliaComputing/OpenAPI.jl#72
* allow configuring jackson, remove jackson import if disabled
* do not generate root resource or application file if generating interface
* change template files to remove jackson if disabled
* updated samples and docs as required by PR checklist
* [rust-axum] Make discriminator field name camelCase
* [rust-axum] Give polymorphic enum values a serde alias using the mapping keys if available
* update samples
* update test file checksum
* Support nullable `org.springframework.web.multipart.MultipartFile` in Kotlin Spring generator
- nullable is only supported for MultipartFile. However, Array<MultipartFile> could be also nullable
* Support nullable `org.springframework.web.multipart.MultipartFile` in Kotlin Spring generator
* Support nullable `org.springframework.web.multipart.MultipartFile` in Kotlin Spring generator
Update kotlin-spring-additionalproperties samples
