They were never really intended to support null values, so this is kind of a bug. However, this is technically also breaking for users that set these properties to `null` explicitly (instead of leaving them unset).
* Correctly apply Gradle task input & output annotations to accessors
Gradle's task input and output annotations should be applied to the accessors instead of the properties. No adhering to this can cause funky behavior in the generated stubs. Examples of this can be found in the docs: https://docs.gradle.org/current/userguide/implementing_custom_tasks.html
Also adds missing annotations so that validation passes
* Enable strict Gradle plugin validation
* [Bugfix][Maven-Plugin] Bugfix for remote input specs with parameters
If the inputSpec was a web address that contained parameters, code generation would fail, because the filepath would contain illegal characters, since the code inside the if-block would be skipped. A side effect of this was, that in the log and in the filename in linux the parameters would be leaked, which could potentially sensitive information like Gitlab Access Tokens
* [Test][Gradle Plugin] Update GenerateTaskDslTest.kt
Extended the Test for testing remote inputSpecs with urlParams, a case that caused problems in the maven plugin.
Introduced a new property `inputSpecRootDirectorySkipMerge` to conditionally skip the merging step of the specification files. Updated the logic to honor this new property, ensuring merging only occurs if it is explicitly not skipped. Enabled configuration via Gradle build file.
* Specify exact relative path to parent pom.xml
* Remove org.reflections from the test stack
* Remove unused parameter
* Remove unused method
* Fix raw use of parameterized variable warning
* Use Files.readString instead of converting raw bytes
* Add test coverage for TestUtils.validatePomXmlFiles(List)
* Reimplement TestUtils.validatePomXmlFiles(List) with Jackson XML mapper
* Remove maven-rewrite dependency
* 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
