Re: microprofile openapi @asf?

[Andriy Redko]

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  a 
écrit :




RMB> Le dim. 24 juin 2018 21:59, Andriy Redko  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 A

Re: microprofile openapi @asf?

[Romain Manni-Bucau]

Hi guys,

Just to update you: we just passed the TCK. Impl is likely not perfect but
I proposed @geronimo to start a 1.0.0 vote with that since we are tck
friendly and then iterate with the classical reports/bugs/... flow.
I introduced a very light reflection abstraction to isolate most of the
logic from CDI so assuming the scanning logic is rewritten (this is not
much code but it is technology specific) then it should be quite easy to
make it 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).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 24 juin 2018 à 23:04, Romain Manni-Bucau  a
écrit :

>
>
> Le dim. 24 juin 2018 21:59, Andriy Redko  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 semanti

Re: Help wanted please :-)

[John D. Ament]

I attached a screenshot of the javascript errors that are popping up as
well.

On Sun, Jul 8, 2018 at 9:30 AM Andriy Redko  wrote:

> Done, https://issues.apache.org/jira/browse/INFRA-16736 (linked to
> Francesco's ticket as well).
>
> CS> I see the same problem. It also happens for other builds outside CXF.
> CS> Can you open an INFRA issue?
>
>
> CS> Christian
> CS> Am So., 8. Juli 2018 um 00:37 Uhr schrieb Andriy Redko <
> drr...@gmail.com>:
>
> CS> Hey guys,
>
> CS>  I would really appreciate if someone could help. I have created the
> Jenkins build for 3.2.x
> CS> (https://builds.apache.org/job/CXF-3.2.x) out of the CXF-Trunk-JDK18.
> For some reasons, the configuration page
> CS> (https://builds.apache.org/job/CXF-3.2.x/configure) never loads for
> me, always stuck in "Loading" spinner (tried it
> CS> many times during the day), so I cannot change the branch to
> */3.2.x-fixes for this job. Anyone would be able to help me there (or hint
> the workaround)? Thanks!
>
> CS>  Best Regards,
> CS>  Andriy Redko
>
>
>
>
>
> CS> --
>
>

Re: Help wanted please :-)

[Andriy Redko]

Done, https://issues.apache.org/jira/browse/INFRA-16736 (linked to Francesco's 
ticket as well).

CS> I see the same problem. It also happens for other builds outside CXF. 
CS> Can you open an INFRA issue? 


CS> Christian
CS> Am So., 8. Juli 2018 um 00:37 Uhr schrieb Andriy Redko :

CS> Hey guys,

CS>  I would really appreciate if someone could help. I have created the 
Jenkins build for 3.2.x
CS> (https://builds.apache.org/job/CXF-3.2.x) out of the CXF-Trunk-JDK18. For 
some reasons, the configuration page
CS> (https://builds.apache.org/job/CXF-3.2.x/configure) never loads for me, 
always stuck in "Loading" spinner (tried it
CS> many times during the day), so I cannot change the branch to */3.2.x-fixes 
for this job. Anyone would be able to help me there (or hint the workaround)? 
Thanks!

CS>  Best Regards,
CS>  Andriy Redko





CS> --