The only special handling was for security definition type `apiKey`
in `query`. All the other security configurations should result in the
same generated code.
Moves the handling of the special query parameters outside of the
`parameters without specific cardinality` section.
To cover the scenario where `elif` was being used, simply leverage the
builtin `continue` statement to stop processing the specific query
parameter and continue to the next available query parameter, if any.
Manually test with multiple different combinations.
Resolves: #6526
When a spec defines a Model at the top level that is a non-aggretate type (such
as string, number or boolean), it essentially represents an alias for the simple
type. For example, the following spec snippet creates an alias of the boolean
type that for all intents and purposes acts just like a regular boolean.
definitions:
JustABoolean:
type: boolean
This can be modeled in some languages through built-in mechanisms, such as
typedefs in C++. Java, however, just not have a clean way of representing this.
This change introduces an internal mechanism for representing aliases. It
maintains a map in DefaultCodegen that tracks these types of definitions, and
wherever it sees the "JustABoolean" type in the spec, it generates code that
uses the built-in "Boolean" instead.
This functionality currenlty only applies to Java, but could be extended to
other languages later.
The change adds a few examples of this to the fake endpoint spec for testing,
which means all of the samples change as well.
* Removed trailing spaces
* Fixed autocomplete support for bash-completion < 1.4
* Added mime type autocomplete for Zsh
* Fixed Bash url autocompletion
* Fixed Zsh space after operation arguments and added trim to descriptions
* Added generation of Dockerfile for packaging Bash rest clients
* updated test samples for Bash client generator
