Hi Romain, Just went through the issues and comment threads. I am not really involved in MP (sadly) but the YAML+JSON discussion makes sense to me, at least from the platform perspective. JSON should be a must, YAML is optional (although it is very popular in OpenAPI community). My personal position regarding the builder vs annotations is a matter of choice / preference. There are centainly pros and cons of both, valid arguments are listed. I don't think either of them is perfect for everyone, supporting both options sounds like a good trade-off, let devs pick whatever fits better to the particular project / context.
The issue related to model serialization takes unexpected turn towards https://github.com/OpenAPITools project ... I don't know the full details but afaik these guys are forking Swagger projects (swagger-codegen notably) and rebranding under OpenApiTools umbrella. I am working on the PR https://github.com/swagger-api/swagger-codegen-generators/pull/101 to replace code generation of old Swagger / OpenAPI 2.x with OpenAPI 3.x (since Apache CXF supports that out of the box). If things work out here as expected, I would be happy to help to introduce MP part (server stubs or/and client) as well. Thanks. Best Regards, Andriy Redko RMB> Hi guys, RMB> opened several issues about the spec and a few of them are serious concerns RMB> for me (others are easier): RMB> 1. https://github.com/eclipse/microprofile-open-api/issues/231 RMB> 2. https://github.com/eclipse/microprofile-open-api/issues/230 RMB> 3. https://github.com/eclipse/microprofile-open-api/issues/228 RMB> Seems like there was no time to think about an API so swagger was just RMB> copied (and adapted to openapi) which leads to something quite inconsistent RMB> for end users and also inconsistent with the platform. RMB> It doesn't prevent us to implement it but would be great if some of you can RMB> check out issues and potentially vote for them. There is no Strong API RMB> stability requirement at microprofile so there is stilla hope the API is RMB> made simpler and usable by end users. RMB> In short (if you don't want to open the links) the issues are: RMB> 1. YAML is mandatory but there is nothing standard to modelize it so it is RMB> an internal of the implementation and the format is not user friendly until RMB> you use something outside the spec RMB> 2. The model is using OpenAPI object graph but it is not integrated with RMB> JSON-B so it is not (de)serializable correctly for end user. It also breaks RMB> the JAXRS serialization since each single object of the graph will need a RMB> custom message reader/writer to work (but the spec doesnt spec about that RMB> so payloads will not be the expected ones, in particular if you send back RMB> from a client which got OpenAPI instance some subgraph!) RMB> 3. There are 2 API in the spec: a builder one and an annotation driven one. RMB> The builder is sufficient and associated with a startup event allows to RMB> avoid the annotations need which just duplicates the builder 1-1 with very RMB> few semantic differences for ref and map management. RMB> In one sentence it means that the API could be easier, less ambiguous for RMB> end users, the integration with the platform more consistent and that it is RMB> a very simple investment and work. It just needs to be made portable RMB> accross vendor. RMB> Romain Manni-Bucau RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog RMB> <https://rmannibucau.metawerx.net/> | Old Blog RMB> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book RMB> <https://www.packtpub.com/application-development/java-ee-8-high-performance> RMB> Le jeu. 21 juin 2018 à 16:20, Raymond Auge <raymond.a...@liferay.com> a RMB> écrit : >> Great! >> On Thu, Jun 21, 2018 at 10:12 AM, Romain Manni-Bucau < >> rmannibu...@gmail.com> wrote: >>> @Raymond: the diff between CDI and OSGi will be where the OpenAPI >>> instance will be created mainly so very doable (aries can even import >>> G-openapi for that). Only diff which can be quite intrusive is that @G we >>> don't use plain reflection to enable CDI meta model to be mutated during >>> startup and therefore let the user configure most of the model instead of >>> hardcoding it, but it is not that hard to abstract so I'm very confident to >>> keep it abstracted and to support OSGi once we support the spec with CDI >>> (and why not supporting CDI in aries ;)). >> Regarding supporting CDI in Aries ;) it should look pretty much like any >> normal CDI extension with a tiny amount of extra OSGi metadata and what I >> hope are very reasonable restrictions on how extensions provide beans, if >> any. >> Sincerely, >> - Ray >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> Le jeu. 21 juin 2018 à 15:21, Raymond Auge <raymond.a...@liferay.com> a >>> écrit : >>>> It would be _nice_ if we could figure out a way for this to be usable by >>>> Apache Aries JAXRS Whiteboard [1] which is an implementation of OSGi JAXRS >>>> Whiteboard [2]. >>>> It would seem that a small SPI on the part of Geronimo's mp-openapi >>>> might be enough (so as not to pressure this up onto the mp spec). >>>> [1] https://github.com/apache/aries-jax-rs-whiteboard >>>> [2] https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html >>>> On Thu, Jun 21, 2018 at 9:06 AM, Mark Struberg < >>>> strub...@yahoo.de.invalid> wrote: >>>>> I think it fits well to geronimo. >>>>> The question is rather if CXF is fine with relying on CDI for openapi? >>>>> But since MicroProfile _requires_ CDI I think there is safe to assume >>>>> so. >>>>> LieGrue, >>>>> strub >>>>> > Am 21.06.2018 um 09:59 schrieb Romain Manni-Bucau < >>>>> rmannibu...@gmail.com>: >>>>> > >>>>> > Hello guys, >>>>> > >>>>> > we created a repo for that and to be able to share what we do: >>>>> > https://gitbox.apache.org/repos/asf?p=geronimo-openapi.git >>>>> > >>>>> > I pushed a basic starting structure of the code. The big TODO is the >>>>> > conversion from the model (annotations) to OpenAPI instance (which >>>>> should >>>>> > be somewhere here >>>>> > >>>>> https://gitbox.apache.org/repos/asf?p=geronimo-openapi.git;a=blob;f=src/main/java/org/apache/geronimo/microprofile/openapi/impl/processor/AnnotationProcessor.java;h=141227b579495e2b072710fadb28f2d08ab07616;hb=HEAD >>>>> > or split in multiple "visitors" if desired). >>>>> > >>>>> > If anyone wants to help it is welcomed. Also note it is not too late >>>>> to >>>>> > change the project hosting or other details if there is some points we >>>>> > missed until now. >>>>> > >>>>> > Romain Manni-Bucau >>>>> > @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>> > <https://rmannibucau.metawerx.net/> | Old Blog >>>>> > <http://rmannibucau.wordpress.com> | Github < >>>>> https://github.com/rmannibucau> | >>>>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >>>>> > < >>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance >>>>> > >>>>> > >>>>> > >>>>> > Le mar. 19 juin 2018 à 07:39, Romain Manni-Bucau < >>>>> rmannibu...@gmail.com> a >>>>> > écrit : >>>>> > >>>>> >> Basically read metadata from AnnotatedTypes (cdi) used by jaxrs cdi >>>>> >> extension. Im not yet sure i will need the extension itself or not >>>>> (doesnt >>>>> >> seem hard to not use it for that and would stay portable). >>>>> >> >>>>> >> >>>>> >> Le mar. 19 juin 2018 00:36, Andriy Redko <drr...@gmail.com> a écrit >>>>> : >>>>> >> >>>>> >>> Hey Romain, >>>>> >>> >>>>> >>> Thanks for starting work on that. Indeed, >>>>> >>> https://issues.apache.org/jira/browse/CXF-7601 is >>>>> >>> opened but not started yet, sadly. So what is your plan / scope, >>>>> generate >>>>> >>> the OpenAPI 3.x >>>>> >>> specs from JAX-RS 2.1 metadata? Or someting else? May be we could >>>>> also >>>>> >>> help you with that? >>>>> >>> Thanks! >>>>> >>> >>>>> >>> Best Regards, >>>>> >>> Andriy Redko >>>>> >>> >>>>> >>> RMB> Independent, cdi based (not reflection based) >>>>> >>> >>>>> >>> RMB> Le lun. 18 juin 2018 22:34, John D. Ament < >>>>> johndam...@apache.org> a >>>>> >>> écrit : >>>>> >>> >>>>> >>>>> If it's hosted at Geronimo will it be platform independent? Or >>>>> only >>>>> >>> work >>>>> >>>>> with CXF? >>>>> >>> >>>>> >>>>> On Mon, Jun 18, 2018, 3:30 PM Romain Manni-Bucau < >>>>> >>> rmannibu...@gmail.com> >>>>> >>>>> wrote: >>>>> >>> >>>>> >>>>>> Hi guys, >>>>> >>>>>> >>>>> >>>>>> I'm planning to implement microprofile-openapi at geronimo (next >>>>> to >>>>> >>> other >>>>> >>>>>> microprofile specs) soon (probably beginning of next month). >>>>> Before >>>>> >>> doing >>>>> >>>>>> so I wanted to get in touch with you to ensure it was not already >>>>> >>> there >>>>> >>>>>> (@asf). I know CXF has a swagger impl but here, we speak about a >>>>> new >>>>> >>> API >>>>> >>>>>> and I hope to make it dep free and aligned on other geronimo >>>>> impls >>>>> >>>>>> (assuming jsonb+jaxrs+cdi is in the server already which is very >>>>> >>>>> acceptable >>>>> >>>>>> for a MP server). >>>>> >>>>>> >>>>> >>>>>> Anything I should check before launching the project or is the >>>>> road >>>>> >>> as >>>>> >>>>> open >>>>> >>>>>> as I think? >>>>> >>>>>> >>>>> >>>>>> Technical side note: compared to the MP rest client which was way >>>>> >>> easier >>>>> >>>>> to >>>>> >>>>>> impl @cxf cause all the code was already there, the openapi is >>>>> more >>>>> >>> based >>>>> >>>>>> on CDI than CXF internal model so not hosting it @cxf is not an >>>>> >>> issue for >>>>> >>>>>> this one so don't feel any pressure please. >>>>> >>>>>> >>>>> >>>>>> Thanks, >>>>> >>>>>> Romain Manni-Bucau >>>>> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>> >>>>>> <http://rmannibucau.wordpress.com> | Github < >>>>> >>>>>> https://github.com/rmannibucau> | >>>>> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >>>>> >>>>>> < >>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance >>>>> >>>>>>> >>>>> >>>>>> >>>>> >>> >>>>> >>> >>>>> >>> >>>> -- >>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>> (@rotty3000) >>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>>> (@Liferay) >>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >>>> (@OSGiAlliance) >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >> (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >> (@OSGiAlliance)
