* Add maven-compiler-plugin plugin in Java pom.xml and enable linter checks by default
* Add maven-compiler-plugin plugin in Java pom.xml and enable linter checks by default
* use more recent version of maven-surefire-plugin
* use more recent version of maven-surefire-plugin
* higher debug level for troubleshooting ci issue
* temporarily increase debug log to help troubleshoot
* Use local instance of pet store service for unit test purpose
* Add more logging to troubleshoot unit test failures
* Add more logging to troubleshoot unit test failures
* Add more logging to troubleshoot unit test failures
* Add more logging to troubleshoot unit test failures
* Add more logging to troubleshoot unit test failures
* use random ID for Java unit test instead of fixed id
* add code comments and specify URL for java unit test
* reenable quiet argument
* fix java unit test issues
* fix java unit test issues
* Revert "fix java unit test issues"
This reverts commit e8508416ff0f2aeb568e3f916b013dc967390f74.
* fix java unit test issues
* Resolves `An error has occurred in Javadoc report generation: [ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules but the packages defined in https://docs.oracle.com/javase/8/docs/api/ are in the unnamed module` error that happens when using Java 11
* Resolves `An error has occurred in Javadoc report generation: [ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules but the packages defined in https://docs.oracle.com/javase/8/docs/api/ are in the unnamed module` error that happens when using Java 11
* Fix duplicate configuration entries
* Fix okhttp poms
* Remove letter that shouldn't be there
* 3432 Use builder api of OkHttpClient to avoid UnsupportedOperationEx
The reason for the UnsupportedOperationException was an invalid access to the interceptors list of OkHttpClient. That list is unmodifiable as stated by the JavaDoc. Instead accessing the list directly, the interceptors should always be passed when building the client by the builder api.
* 3432 Use builder api of OkHttpClient to avoid UnsupportedOperationEx
The reason for the UnsupportedOperationException was an invalid access to the interceptors list of OkHttpClient. That list is unmodifiable as stated by the JavaDoc. Instead accessing the list directly, the interceptors should always be passed when building the client by the builder api.
* 3432 Follow-up fix to make samples compile again
* 3432 Updated sample implementation for okHttp-Gson-ParcelableModel
* [core] Move overwrite ownership to SupportingFile
Previously, there was a writeOptional method in DefaultCodegen which
allowed *Codegen instances to immediately write out a supporting file if
it did not exist. This would allow a codegen implementation to skip
user-facing options such as definitions in .openapi-codegen-ignore, the
"supportingFiles" system property, and support for the experimental
handlebars templating engine. While our implementation only modified the
supportingFiles list conditionally, it added confusion as it seemed to
imply that file writes were somewhat the responsibility of
DefaultCodgen (it's DefaultGenerator which handles file manipulation).
This commit moves the definition of whether a file supports overwriting
existing files into the SupportingFile type itself, allowing that
functionality to be determined at time-of-write rather than
time-of-definition. This would allow us, for example, to dump the list
of files which would be generated using a --dry-run option or similar.
This will be a breaking change for anyone who has extended
DefaultCodegen and called "writeOptional". The path to migrate is to add
the SupportingFile to the supportingFiles list and chain the method call
`.doNotOverwrite()` on the instance.
This has the added benefit of clarifying this behavior, considering the
write behavior wasn't previously "optional" writes but optionally
defining the list of supportingFiles based on the state of the file
system.
* [samples] Regenerated
* Use builder pattern for requests
* petstore
* Add @throws annotation
* regenerate jersey2 test files
* Also group bodyParam in builder class
* petstore java6
* regenerate java8
* ensure up to date
* Fix for Issue #2205
Because when we have tags on OpenAPI Specification, there can be more than 1 Feign Beans being generated and the title field is share by all the clients. This makes the code to stop working in runtime.
Here is a PR which uses the classVarName instead, which follows the standards and should be enough to solve this issue.
For more info please refer to: https://github.com/OpenAPITools/openapi-generator/issues/2205
* fix java feign parameter request name (#4883)
* update sprign cloud feign sample
* [JAVA][SPRING][2195] added missing getter for enum value (#2346)
* [2195] added missing getter for enum value
* updated samples
* re-generate spring samples
* Removed @JsonValue from toString and regenerated samples
* re-generate spring samples
Co-authored-by: Esteban Gehring <esteban.gehring@gmail.com>
* update samples
* [kotlin][client] make Request date converter toJson as default
* [kotlin][client] update windows scripts
* [kotlin][client] update docs
* [kotlin][client] update scripts
* [kotlin][client] update scripts
Co-authored-by: Filipe Manuel Couto Pinheiro <filipemcpinheiro@gmail.com>
Co-authored-by: William Cheng <wing328hk@gmail.com>
Co-authored-by: Lukáš Vasek <bilaak@gmail.com>
Co-authored-by: Esteban Gehring <esteban.gehring@gmail.com>
* Example of broken multi-level hierarchy
* Support for multiple levels of hierarchy in model objects
* Support for multiple levels of hierarchy in generators
* Regenerated samples
* Temporarily skip scalaz sample verification, which is having issue with Java version in CI container
* Re-enable scalaz in verify samples
Co-authored-by: Rob Oxspring <roxspring@imapmail.org>
