9c999b6559
* 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
5.4 KiB
| id | title |
|---|---|
| globals | Global Properties |
Available Global Properties
| Property | Description | Acceptable value |
|---|---|---|
| debugOpenAPI | Dumps JSON formatted and fully parsed OpenAPI document during generation | none |
| debugModels | Dumps JSON formatted template-bound model information during generation | none |
| debugOperations | Dumps JSON formatted template-bound operation information during generation | none |
| debugSupportingFiles | Dumps JSON formatted Supporting File information during generation | none |
| verbose | Defines the verbosity | true or false |
| generateAliasAsModel | Defines whether primitive types defined at the model/schema level will be wrapped in a model | true or false |
| org.openapitools.codegen.utils.oncelogger.enabled | Enable/disable the "OnceLogger" which reduces noise for select repeated logs | true or false |
| supportingFiles | Allows the user to define which supporting files will be generated. Prefer using the more robust .openapi-generator-ignore. |
no value, or a colon-separated string of file names |
| models | Allows the user to define which models will be generated. Prefer using the more robust .openapi-generator-ignore. |
no value, or a colon-separated string of model names |
| apis | Allows the user to define which apis will be generated. Prefer using the more robust .openapi-generator-ignore. |
no value, or a colon-separated string of api names |
| apiDocs | Allows the user to define if api docs will be generated. Prefer using the more robust .openapi-generator-ignore. |
true or false |
| modelDocs | Allows the user to define if model docs will be generated. Prefer using the more robust .openapi-generator-ignore. |
true or false |
| apiTests | Allows the user to define if api tests will be generated. Prefer using the more robust .openapi-generator-ignore. |
true or false |
| modelTests | Allows the user to define if model tests will be generated. Prefer using the more robust .openapi-generator-ignore. |
true or false |
Note on Global Property declaration
There are two ways to provide selective generation properties or "global properties". First, these can be passed as Java System Properties. Second, these can be passed via the global property tooling option (--global-property in CLI and globalProperty in Maven and Gradle configurations). This differentiation is new in version 5.0 with the removal of the -D CLI option and the renaming of systemProperties. If you're upgrading to OpenAPI Generator 5.0+
While the examples seen in Customization use the Java System Property syntax, keep in mind that the following are equivalent:
java -Dmodels {jar} generate {opts}
and
java {jar} generate {opts} --global-property=models
Why the two differing ways to provide the same properties? We previously accepted a -D tooling option which resembled Java System Property declaration. In older versions of OpenAPI Generator, the option modified the SystemProperties collection directly and was truly a "system property". This option changed during the 4.x release in an effort to make OpenAPI Generator thread-safe and isolate its configuration via thread locals. We no longer mutate System Properties. In the 4.x release and earlier, specifying the tooling -D option with system properties intended for other tools like swagger-parser rather than passing them as true Java System Properties would lead to unexpected behavior for the user; if our tool set the system property after invoking certain code, it would seem to the user like Java System Properties weren't working!