* [java] Improve assumptions about artifactVersion
The logic to apply a default artifactVersion was faulty, resulting in
generation without an explicit version specified either on the OpenAPI
Document or at the CLI/plugin level would result in poms generated with
<version></version>
As an example, in any commit made up to 5 weeks before this commit, run:
./bin/java-pkmst-petstore-server.sh
The solution is to ensure that artifactVersion isn't overwritten by an
"in-process" additonalProperties map, and also to ensure that
additionalProperties is synced with the artifactVersion property once it
has been modified.
As a future task, we'll want to move any modification of
additionalProperties outside of preprocessOpenAPI (to processOpts).
We're hiding manipulation of the "Opts" at a point where we should
really only be applying logic on top of the OpenAPI doc.
* [sample] Regenerate java-pkmst sample
* 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
bin/elm-petstore-all.sh invokes elm-petstore.sh and
elm-0.18-petstore.sh. Both of these define `ELM_POST_PROCESS_FILE` for
post-processing the generated files. If a user doesn't have elm-format
installed, they may not realize that ensure-up-to-date has failed which
causes CI to fail due to differences in the ELM generated outputs.
This confusion can lead to a lot of downtime for contributors. For
example, I encountered this while adding feature set information to all
generators. I thought I had introduced the error and spent too long
looking through my changeset and re-running `ensure-up-to-date`
in the background before noticing the failed output. I was able to
generate proper output by installing elm-format. With 80+ languages/frameworks
and a rule for contributors to unblock CI by re-generating any failed
samples, it's not feasible (in some cases, not possible) to ask
contributors to install tooling specific post-processors. We'll have to
rely on elm contributors to run the script manually.
Ideally, elm generator templates should be updated to have properly
formatted outputs as a default.
We may want to consider documenting standards of what we put in the
scripts under bin/*sh and bin/utils/ensure-up-to-date, one of those
standards being that we omit toolchain specific post-processors.
* 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
When WorkflowSettings was constructed from an existing instance, as is
the case when we deserialize from an external configuration file, it
would result in an error:
Caused by: java.lang.UnsupportedOperationException
at com.google.common.collect.ImmutableMap.put(ImmutableMap.java:450)
at org.openapitools.codegen.config.WorkflowSettings$Builder.withSystemProperty(WorkflowSettings.java:465)
This was due to an error in `newBuilder(WorkflowSettings copy)` which
assigned builder.systemProperties with an immutable map. This is
incorrect because everything in the builder should be mutable until
.build() is invoked.
This likely affects CLI/Maven plugin as well for version 4.1.1 through 4.2.0.
* [meta] Support Kotlin meta generator
* Guard against automatic scripts (assumptions for this script are not fulfilled by some CI which run "run all" type scripts)
Fix Codegen Operation Scope Consistency
- Filter scopes based on operation
- Partially revert #1984 to not rely on custom attributes as to whether scopes exist
- Fix filtering global authentication schemes
