This is great, Romain! Congrats on making a huge progress in such a short term.
Best Regards, Andriy Redko Sunday, July 8, 2018, 2:32:53 PM, you wrote: RMB> Hi guys, RMB> Just to update you: we just passed the TCK. Impl is likely not perfect but I proposed @geronimo to start a 1.0.0 RMB> vote with that since we are tck friendly and then iterate with the classical reports/bugs/... flow. RMB> I introduced a very light reflection abstraction to isolate most of the logic from CDI so assuming the scanning RMB> logic is rewritten (this is not much code but it is technology specific) then it should be quite easy to make it RMB> match CXF. Technically, doing a maven plugin to prebuild the openapi.json is very feasible too (i'm planning to do some tests on this one soon). RMB> Romain Manni-Bucau RMB> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book RMB> Le dim. 24 juin 2018 à 23:04, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : RMB> Le dim. 24 juin 2018 21:59, Andriy Redko <drr...@gmail.com> a écrit : RMB> Hi Romain, RMB> Just went through the issues and comment threads. I am not really involved in MP (sadly) RMB> but the YAML+JSON discussion makes sense to me, at least from the platform perspective. JSON RMB> should be a must, YAML is optional (although it is very popular in OpenAPI community). My personal RMB> position regarding the builder vs annotations is a matter of choice / preference. There are RMB> centainly pros and cons of both, valid arguments are listed. I don't think either of them is RMB> perfect for everyone, supporting both options sounds like a good trade-off, let devs pick whatever RMB> fits better to the particular project / context. RMB> It assumes the ee5 pattern and forgets the cdi/event ones. I agree it is not yet mainstream but it is a RMB> convergence opportunity. In particular when you see all the reference workarounds annotation require and an RMB> event/programmatic solution doesnt. It is a huge gain in practise if you have endpoints using the same models. RMB> Kind of theory vs practise feedback probably. RMB> The issue related to model serialization takes unexpected turn towards https://github.com/OpenAPITools RMB> project ... I don't know the full details but afaik these guys are forking Swagger projects (swagger-codegen notably) RMB> and rebranding under OpenApiTools umbrella. I am working on the PR RMB> 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 RMB> supports that out of the box). If things work out here as expected, I would be happy to help to introduce MP part RMB> (server stubs or/and client) as well. RMB> Yep. My concern here is that using a custom serializer leads to limit the spec usage to the spec endpoint. It is RMB> likely 20% only of the main usages so spec will likely be replaced by something else anyway if it stays as such :(. RMB> Thanks. RMB> Best Regards, RMB> 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)