* Initial work on a redux-query client generator.
* Update to match the required redux-query version w/ fixed TS defs.
* Fixes for query parameters, add samples.
* Add windows versions of redux-query scripts.
* Fix for form data handling.
* Initial work on multiple inheritance support.
* Tweaks for discriminator usage + from/to JSON.
* Fix initialization of queryParameters if needed.
* Copy over more QueryConfig values into the final generated QueryConfig.
* Fix for imports that are combined types.
* FIXES#4539 replace line comment with block comment
eslint requires you to use a block comment for ignoring whole files.
* changed comment style in other templates
* generated samples
* generated openapi3 samples
* Revert "generated openapi3 samples"
This reverts commit 98af3dfc
* generated missing samples
* Validation script batches only samples
In this change, the validation script will batch only sample generation.
For meta and documentation, it will always be iterative.
Also made changes to meta-codegen*.sh so conditionals which may invoke
maven are explicitly rooted.
* [ci] batch python-experimental, include new springboot option
Scalaz is not re-generated by users or CI (only verified), so some
compilation issues have been introduced into the generator.
Specifically, the generator previously didn't handle defaults well (or
even correctly, maybe?). This broke when array models were added to the
openapi document used to generate samples. The inclusion of Date-related
mappings being mapped to joda time in DefaultCodegen also caused some
issues with new DateTime properties on models.
Over the course of what appears to be Nov 10-17 2019, CircleCI seems to
be having intermittent issues with Scalaz verification. I found that
green builds were picking up SBT 0.13.x and failed builds were SBT
1.1.0. It's not clear where the system level SBT is being defined, but a
simple fix has been to enforce the sbt version in the generator.
For those unfamiliar with SBT; the SBT command acts as a launcher script
which may switch to older/newer versions of SBT. A Scala project invoked
with SBT 1.1.0 will look for an sbt.version override and happily attempt
compilation with the available SBT 1.1.0. The problem is that SBT 1.1.0
uses Scala 2.12 and this is not binary compatible with Scala 2.11. This
can cause issues with builds due to plugins or incompatible Java version.
* 4383: Client resttemplate and webclient. Form Params are badly added when they are lists
* 4383: Force redeploy
* 4383: Fix test
* 4383: Fix map
* 4383: revert change
* 4383: Fix test resttemplate-withXml
* Added new additional parameter to allow nullable api return types
* Tweaking samples and .bat files
I've added new .bat files for the kotlin-client to alllow windows-devs to re-generate required samples via windows-shell (for CI).
* Moved example string to a dedicated variable in Spring's methodBody template
* Created a new exampleString template for JavaSpring
* Added a new mustache lambda to trim whitespace in fragments
* Added a new lambda to split long fragments into compilable strings
* Use newly introduced lambdas in Spring's API template to avoid generating uncompilable example code
* fixup! Simpler timeout with QTimer::singleShot (#4430)
* cpp-qt5-client: remove host since it is not well handled
* Move disconnect again
* cpp-qt5-client: handle scheme/host/port properly
* Fix port change try
