* 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>
Co-authored-by: Akihito Nakano <sora.akatsuki@gmail.com>
Co-authored-by: Jeremie Bresson <dev@jmini.fr>
Co-authored-by: Jim Schubert <james.schubert@gmail.com>
Co-authored-by: Martin Delille <martin@phonations.com>
Co-authored-by: Tomasz Prus <tomasz.prus@gmail.com>
Co-authored-by: William Cheng <wing328hk@gmail.com>
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.
- No more presuming 'WWW::' is at the beginning
(default is now "WWW::SwaggerClient" vs "SwaggerClient" in order
to accomodate)
- Test that module names Like::This write to the filesystem and in
the mustache templates properly
- there is no standard way for a swagger spec to define descriptive
information for an endpoint API
- added markdown as a format to the autodoc script
- added some version information to autogenerated docs
- API classes have rudimentary class doc info and useful method doc info
- object classes have more detailed method and class info
- added more tests for doc methods
- remove the optional auth_setup_handler() callback mechanism
- add _global_auth_setup() method on ApiClient to analyse config when
security spec not provided
- add methods on the Configuration class to abstract getting and setting
tokens
- added POD to Role.pm
- added README.md files translated from Role.pm POD
- added an autodoc script (based on AutoDoc.pm role). The script prints
a listing of the methods built in Role.pm
- added class_documentation() and method_documentation() accessors on
all object and API classes which return the documentation supplied in
the Swagger spec for the API
When flattening all endpoint API methods into a single class, some
method names may clash, e.g. every API has a new() method. So we skip
them, they must be accessed via the API method. Warnings are emitted to
document skipped methods.
I've been using http://petstore.swagger.io/v2/swagger.json instead of
modules/swagger-codegen/src/test/resources/2_0/petstore.json as the
input spec for building the petstore. This commit reverts the changes
introduced from that.
ApiFactory provides a get_api() method to generate API objects without
having to hard-code class names. All API and object classes are loaded
automatically.
Also, added proper accessors for attributes of object classes.
At least 2 previous updates were committed without rebuilding the perl
petstore client. One was my fault (BaseObject.pm changes), the other
changes come from an upstream update or updates I can't identify.
