* Mention that Golang generator also supports XML annotations
Looking at src/main/resources/go/model_simple.mustache and
src/main/java/org/openapitools/codegen/languages/GoClientCodegen.java
the GoLang seems to cater for withXml=true
* Fix maven plugin config description for `withXml`
* Add basic test for global withXml setting
* Use global withXml setting if not configured in ConfigOptions
Resolves#3839 and #5764
* Don't generate metadata or other files when only Models are tested
* Reformat table for readability
* Remove global property `withXml` from generator and docs
* Move WITH_XML constant out of system constants block
Currently there is only a single reference to this value in the whole
codebase (GoClientOptionsProvider). Maybe we should re-think how this
file is organised (i.e. provide a clearer split / mapping / understanding
what are system properties vs. global properties vs. configOptions and
where to put them).
* Remove global option `withXml` from Maven plugin (Breaking change)
This is a "soft" breaking change: Plugin will no longer execute if
user have this option – which is good, b/c it never worked as expected.
We may want to hint this in the 8.0 release notes.
* Remove global property `withXml` from Gradle plugin (Breaking change)
This is a "soft" breaking change: Plugin will no longer execute if
user have this option – which is good, b/c it never worked as expected.
We may want to hint this in the 8.0 release notes, so they can add it
to the `configOptions` map if required, or simply delete it
* Update samples to reflect removed `withXml` property
* Move `withXml` option into ConfigOptions for Java Microprofile sample
* Remove unused local vars and parameters
* Avoid repetition using fluent assertions
* Remove extraneous debug output
* Updated Gradle documentation examples to use correct non-deprecated .set(x) syntax instead of directly assigning
* Updated more Gradle documentation examples to use correct non-deprecated .set(x) syntax instead of directly assigning
* Updated documentation to use Java 11 instead of Java 8
* Upgrade Gradle plugin Gradle build to Gradle 7.5.1
* Update Travis workflow file to support new tasks
* Update Maven POM with Gradle 7.5.1
* Capitalize many occurrences of "Gradle" in the Gradle plugin README
* Update Gradle version in appveyor.yml and shippable.yml
* Update comments
* Update Gradle wrapper to 7.5.1
* Capitalize Gradle in shippable.yml
* Leave Open API
* Upgrade Gradle plugin build to Gradle 7.6
* Upgrade wrapper to Gradle 7.6
* [breaking] Enforce vendor extension naming convention
* [breaking] Rename system properties to global properties
* [docs] Update site with global properties list and usage explanation
* Use proper vendor extension casing in all templates
* Set remaining vendor extensions to convention of lower kebab-cased with x- prefix
* [samples] Regenerate
* Update modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/RustServerCodegen.java
Before we were adding hasPathParams twice, once with !op.pathParams.isEmpty(), and then again with hasPathParams. This was probably caused by a mistaken merge.
This is causing the difference in samples
Co-authored-by: Richard Whitehouse <richard.whitehouse@metaswitch.com>
* [Samples] Regenerated!
* Fix -D conversion to additional-properties, missed in bat files
* JERSEY2 option changed
* [samples] Regenerate
* [scala][finch] Fix remaining vendor extensions format to conventino
* [scala] The -D option was replaced with --global-property
* [samples] Regenerate
* Fix -DskipFormModel usage which has been moved to --global-property skipFormModel=true
* [samples] Regenerate
Co-authored-by: Richard Whitehouse <richard.whitehouse@metaswitch.com>
* [gradle] Add recommendations to validate task
* Use current version of Gradle Plugin in build checks.
* Fix gradle project build version confusion in CI
* [gradle] Bump samples to 5.2.1 wrapper
Previously, the Gradle plugin was building in CI against
openapi-generator 4.2.0 and Gradle version 4.10.2. At some point, a
contribution was made with an API which is incomatible at 4.10.2 and due
to a release script error which pinned the local-spec version to release
4.2.0, we didn't notice this inconsistency.
This bumps the project to build against Gradle 5.2.1.
* [doc] Update versions missed during release
Removed old script bin/utils/release_version_update_docs.sh to avoid
confusion. New script solves issues of not "globally" replacing.
New script is at:
bin/utils/release/release_version_update_docs.sh
* Update Gradle Plugin README with correct version
* Update gradle.properties to correct version