Le dim. 24 juin 2018 21:59, Andriy Redko <drr...@gmail.com> a écrit :
> 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. > It assumes the ee5 pattern and forgets the cdi/event ones. I agree it is not yet mainstream but it is a convergence opportunity. In particular when you see all the reference workarounds annotation require and an event/programmatic solution doesnt. It is a huge gain in practise if you have endpoints using the same models. Kind of theory vs practise feedback probably. > 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. > Yep. My concern here is that using a custom serializer leads to limit the spec usage to the spec endpoint. It is likely 20% only of the main usages so spec will likely be replaced by something else anyway if it stays as such :(. > 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) > > >
