* 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
* [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
* 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>
* Update Gradle in generated Java projects from 2.14.1 to 6.0.1
* Upgrade Java 11 native Gradle from 5.5 to 6.0.1
When Java 11 native client library was introduced it was introduced with an overridden version of the Gradle wrapper (5.5 instead of 2.14.1). From looking at that PR, there doesn't appear to be any specific reason for the versions to differ. This removes the only override of the Gradle wrapper so all the Java projects are up to date and shares the same version.
* fixed bug where nullApi.java would be generated. Instead, generated DefaultApi.java to match the default path /{pathParam}
* fix to bug #3157
* update samples
