smallrye-open-api
smallrye-open-api copied to clipboard
smallrye
OAS 3.1 changes for schema model
Build failures are expected because this depends on spec changes.
Locally I have tests passing up to this point:
SmallRye: OpenAPI Test Data ........................ FAILURE [ 10.751 s]
With the failure:
[ERROR] [error]: Build step io.quarkus.smallrye.openapi.deployment.SmallRyeOpenApiProcessor#build threw an exception: java.lang.NoSuchFieldError: org/eclipse/microprofile/openapi/models/media/Schema$SchemaType.NULL
[ERROR] at io.smallrye.openapi.api.models.media.SchemaImpl.setNullable(SchemaImpl.java:330)
[ERROR] at io.smallrye.openapi.runtime.io.schema.SchemaFactory.readSchema(SchemaFactory.java:188)
[ERROR] at io.smallrye.openapi.runtime.io.schema.SchemaFactory.readSchema(SchemaFactory.java:119)
[ERROR] at io.smallrye.openapi.runtime.io.schema.SchemaFactory.readSchema(SchemaFactory.java:94)
[ERROR] at io.smallrye.openapi.runtime.scanner.OpenApiDataObjectScanner.readKlass(OpenApiDataObjectScanner.java:376)
[ERROR] at io.smallrye.openapi.runtime.scanner.OpenApiDataObjectScanner.depthFirstGraphSearch(OpenApiDataObjectScanner.java:251)
which looks like this part of the build is running with the built smallrye-open-api, but using an older version of the spec APIs without SchemaType.NULL.
Found the issue and updated the dependency for the testdata project and now my local build runs cleanly.
@Azquelt , the target branch did not have CI enabled, so I've added it. We should get the test jobs running against the SNAPSHOT MP OpenAPI 4.0 build on your next rebase/push.
I've updated the serialization code so that all the "xxxIO" objects are created and owned by IOContext and implemented the serialization of any model object as a child of a schema.
Unfortunately I found some mistakes in the tests in this area which are fixed by eclipse/microprofile-open-api#602. The code in this PR should pass all tests once that PR is merged.
@Azquelt I just fast-forwarded main-4.0 to the current main. There are conflicts, but nothing looks terrible.
@MikeEdgar I've rebased this on the updated main-4.0 branch to resolve the conflicts and I think it's ready for review
Let go, we can roll forward. Would this cause a breaking change in Quarkus, or is it backwards compatible ?
Let go, we can roll forward. Would this cause a breaking change in Quarkus, or is it backwards compatible ?
This and other MP OpenAPI changes are going into the main-4.0 branch for now, so we won't release that until everything is completed and we'll bump the major version at that point.
Just branch of current main into a tag for in case we need to do work on that branch.