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 <[email protected]> a
écrit :
RMB> Le dim. 24 juin 2018 21:59, Andriy Redko <[email protected]> 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 <[email protected]> a
RMB>> écrit :
>>> Great!
>>> On Thu, Jun 21, 2018 at 10:12 AM, Romain Manni-Bucau <
>>> [email protected]> 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 <[email protected]> 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 <
>>>>> [email protected]> 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 <
>>>>>> [email protected]>:
>>>>>> >
>>>>>> > 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 <
>>>>>> [email protected]> 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 <[email protected]> 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 <
>>>>>> [email protected]> 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 <
>>>>>> >>> [email protected]>
>>>>>> >>>>> 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)
