MicroProfile OpenAPI Models #17
Conversation
Signed-off-by: Michael Glavassevich <mrglavas@ca.ibm.com>
Signed-off-by: Michael Glavassevich <mrglavas@ca.ibm.com>
Signed-off-by: Michael Glavassevich <mrglavas@ca.ibm.com>
Signed-off-by: Michael Glavassevich <mrglavas@ca.ibm.com>
Model merge
Signed-off-by: leochr <leojc@ca.ibm.com>
Add OAS factory and resolver
Signed-off-by: janamanoharan <jana.manoharan96@gmail.com>
Signed-off-by: janamanoharan <jana.manoharan96@gmail.com>
My branch 2
Signed-off-by: Anna Safonov <anna.safonov@ibm.com>
Updated models javadocs and changed to ref
Signed-off-by: Anna Safonov <anna.safonov@ibm.com>
… into updateModels Signed-off-by: Anna Safonov <anna.safonov@ibm.com>
Update javadocs for Scopes, OAuthFlow and OAuthFlows models
Signed-off-by: Arthur De Magalhaes <ademagalhaes@gmail.com>
Updating doc Signed-off-by: Arthur De Magalhaes <ademagalhaes@gmail.com>
…and License Signed-off-by: janamanoharan <jana.manoharan96@gmail.com>
added docs for responses and RequestBody. Fixed a few things in Info …
…eValues to enumeration in annotations. Signed-off-by: Anna Safonov <anna.safonov@ibm.com>
… into updateModels
… into updateModels Signed-off-by: Anna Safonov <anna.safonov@ibm.com>
… into updateModels Signed-off-by: Anna Safonov <anna.safonov@ibm.com>
Signed-off-by: Paul Gooderham <turkeyonmarblerye@gmail.com>
is not in the spec. Delete LinkParameter because it is no longer used. 8732 Signed-off-by: Paul Gooderham <turkeyonmarblerye@gmail.com>
Signed-off-by: Paul Gooderham <turkeyonmarblerye@gmail.com>
Signed-off-by: Paul Gooderham <turkeyonmarblerye@gmail.com>
Signed-off-by: Paul Gooderham <turkeyonmarblerye@gmail.com>
HeaderParameter, PathParameter and QueryParameter. Modify the model of Mediatype to conform to the spec. 8732 Signed-off-by: Paul Gooderham <turkeyonmarblerye@gmail.com>
Update Server, ServerVariable, and ServerVariables models
Signed-off-by: Anna Safonov <anna.safonov@ibm.com>
… into updateModels
Update XML model
Signed-off-by: Michael Glavassevich <mrglavas@ca.ibm.com>
Adding documentation to the Constructible interface.
Signed-off-by: Paul Gooderham <turkeyonmarblerye@gmail.com>
…rom Schema.java 8908 Signed-off-by: Paul Gooderham <turkeyonmarblerye@gmail.com>
javadoc and model update
Update the Javadoc in the schema classes. Remove field name methods f…
Signed-off-by: Michael Glavassevich <mrglavas@ca.ibm.com>
Factor out base interface for 'reference' objects.
|
Please note that the failed ip-validation is a bug in eclipse's validation tool, which is incorrectly flagging the PR commits from |
|
@Emily-Jiang - can you please take a look into this PR? Thanks. |
|
@arthurdm I started last night and will continue tomorrow. It is a fairly big PR. |
|
Thanks Emily. As we discussed, this sample helps visualize the programming model that we're going to use the models for: https://github.com/microservices-api/oas3-configuration/blob/master/sample.oas.programmingModels/src/io/swagger/sample/config/OpenAPIConfigurationImpl.java#L23 |
|
This PR looks good to me. I'm not sure if there is a policy in place regarding squashing commits for a PR, but my suggestion would be to squash all the commits into a single commit for each accepted PR. It cleans up the codebase a lot, but at a loss of some detail/fidelity. Probably personal preference. :) Otherwise I give this a 👍 and 🎆 |
|
Merged this. Though the PR has a warning of complaining ip validation, Arthur said this is an Eclipse bug and further to the discussion on the mailing list, this should not block the merging. |
7 participants
Initial drop for #5
This set of models will allow application devs to build an OpenAPI v3 tree programmatically (either a complete tree, or to augment or filter the annotations).
This initial drop introduces the models, while subsequent PRs will introduce filtering, model configuration, etc.
Consider 3 scenarios where these models will be used:
(1) The app developer wants to programmatically create an OpenAPI v3 document (ie: think of a DOM tree) instead of using annotations or pre-generating a YAML document.
(2) The app developer wants to build a "starter model" that will be used as the base OAS3 tree populated during annotation processing. For example: they might use this approach to pre-populate the leading elements such as Info, License, etc, to keep it separated from the REST models.
(3) The app developer wants to filter or augment certain parts of the OpenAPI application dynamically depending on the environment. They can setup a filter (upcoming PR) that will inject the current model tree and allow for filtering / augmentation.