[GitHub] [geronimo-openapi] jgallimore commented on pull request #21: Make org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExte…

2020-05-04 Thread GitBox 


jgallimore commented on pull request #21:
URL: https://github.com/apache/geronimo-openapi/pull/21#issuecomment-623565386


   Thanks @rmannibucau !



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [geronimo-openapi] rmannibucau commented on pull request #20: Skip @RegisterRestClient

2020-05-04 Thread GitBox 


rmannibucau commented on pull request #20:
URL: https://github.com/apache/geronimo-openapi/pull/20#issuecomment-623559846


   Hehe, indeed, was the option "up to you" ;)



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [geronimo-openapi] jgallimore commented on pull request #20: Skip @RegisterRestClient

2020-05-04 Thread GitBox 


jgallimore commented on pull request #20:
URL: https://github.com/apache/geronimo-openapi/pull/20#issuecomment-623558249


   PR for option (2) here: https://github.com/apache/geronimo-openapi/pull/21



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [geronimo-openapi] jgallimore opened a new pull request #21: Make org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExte…

2020-05-04 Thread GitBox 


jgallimore opened a new pull request #21:
URL: https://github.com/apache/geronimo-openapi/pull/21


   …nsion#findEndpointsAndApplication protected to enable the method to be 
overridden in subclasses
   
   See https://github.com/apache/geronimo-openapi/pull/20 for discussion.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [geronimo-openapi] jgallimore commented on pull request #20: Skip @RegisterRestClient

2020-05-04 Thread GitBox 


jgallimore commented on pull request #20:
URL: https://github.com/apache/geronimo-openapi/pull/20#issuecomment-623555356


   Hey @rmannibucau , thanks for the review!
   
   Could I do option (2) and send a PR for that? Making that method protected 
would likely be perfect for what I need to do, is likely the simplest change.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [geronimo-openapi] rmannibucau commented on pull request #20: Skip @RegisterRestClient

2020-05-04 Thread GitBox 


rmannibucau commented on pull request #20:
URL: https://github.com/apache/geronimo-openapi/pull/20#issuecomment-623553039


   Hi @jgallimore ,
   
   most of our users don't use mp-rest-client (plain JAXRS 2 client AFAIK) so I 
think we shouldnt import it and break if not in the classpath (extension code).
   
   There is also a case MP forget there: you create a contract (as an 
interface), create the dynamic client (@RegisterRestClient) from it AND 
implement it (server so it must end up in openapi) - this is a not that rare 
pattern in uservice proxies these days. This change breaks this use case I 
think.
   
   
   I see multiple options there (none perfect):
   
   1. configure the tck through standard MP openapi excludes config entry 
(think it is not insane by itself to ask the user to exclude a bean he does not 
want in the openapi.json)
   2. (likely very tomee oriented) make findEndpointsAndApplication (or new 
method) protected and in tomee you skip default impl in favor of a subclass
   3. add config to enrich the ignore logic
   4. add a SPI to ignore bean, it can take the form of a fireEvent(new 
FindFilter()) in BeforeBeanDiscovery of the extension, another extension will 
observe it do an event.registerFilter(Predicate>) and use that 
in findEndpointsAndApplication
   
   side note: not very important and unrelated to this particular pr but think 
we should move the typename check before the annotation check no?
   
   personally I think 1 is sane but I can understand 4 makes sense too. I'm not 
a fan at all of 3 since it will make it more complex for a poor gain IMHO.
   
   Hope it makes sense.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [geronimo-openapi] jgallimore opened a new pull request #20: Skip @RegisterRestClient

2020-05-04 Thread GitBox 


jgallimore opened a new pull request #20:
URL: https://github.com/apache/geronimo-openapi/pull/20


   When an implementation of MicroProfile REST client is available on the 
classpath, the AirlinesAppTest TCK test fails, as the 
`org.eclipse.microprofile.openapi.apps.airlines.resources.PlayerService` bean 
is incorrectly included in the set of endpoints.
   
   Test failure details:
   
   ```
   [ERROR] Failures: 
   [ERROR] 
org.eclipse.microprofile.openapi.tck.AirlinesAppTest.testRestClientNotPickedUp(org.eclipse.microprofile.openapi.tck.AirlinesAppTest)
   [ERROR]   Run 1: 
AirlinesAppTest>Arquillian.run:138->testRestClientNotPickedUp:191 1 expectation 
failed.
   JSON path paths.'/player/{playerId}' doesn't match.
   Expected: null
 Actual: {get={operationId=getPlayerById, 
responses={200={description=default response, 
content={application/json={schema={type=string, 
default={description=default response, 
content={application/json={schema={type=string}, 
parameters=[{schema={type=string}, in=path, name=playerId, style=simple, 
required=true}]}}
   
   [ERROR]   Run 2: 
AirlinesAppTest>Arquillian.run:138->testRestClientNotPickedUp:191 1 expectation 
failed.
   JSON path paths.'/player/{playerId}' doesn't match.
   Expected: null
 Actual: {get={operationId=getPlayerById, 
responses={200={description=default response, 
content={application/json={schema={type=string, 
default={description=default response, 
content={application/json={schema={type=string}, 
parameters=[{schema={type=string}, in=path, name=playerId, style=simple, 
required=true}]}}
   
   ```



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[RESULT] [VOTE] Apache Geronimo Specs JCDI_2.0 1.2, Annotation_1.3 1.3, AtInject_1.0 1.2, Interceptor_1.2 1.2, JSONP_1.1 1.4, JSONB_1.0 1.3

2020-05-04 Thread Romain Manni-Bucau 
Which makes 5 +1 (3 bindings) so this vote passes, thank you guys.

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



Le lun. 4 mai 2020 à 09:01, Romain Manni-Bucau  a
écrit :

> My own +1
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le lun. 4 mai 2020 à 09:00, Mark Struberg  a écrit :
>
>> +1 because it allows us to more forward quickly.
>>
>> Over the mid- and long-term we will need a separate branch/project I
>> fear.
>> There are already slight differences in e.g. EJB, and a few other specs.
>> But for now this is sufficient enough for people to start playing with.
>> Just keep in mind that we will finally change artifact coordinates!
>>
>> LieGrue,
>> strub
>>
>>
>> Am 28.04.2020 um 19:28 schrieb Romain Manni-Bucau > >:
>>
>>
>>
>> Le mar. 28 avr. 2020 à 18:25, Mark Struberg  a écrit :
>>
>>> As explained in the other thread:
>>>
>>> What is the difference between the various specs and their previous
>>> versions?
>>> Afaict the only difference is jakartaEE, and we WILL  NOT MANAGE to do
>>> all via simple replacement. This is an absolute dead end.
>>>
>>
>> Mark, you keep saying that but each time I ask for a proof of that you
>> never answer.
>> Most of the spec are 1-1 (it was the deal of jakartaee8 and some spec had
>> been forbidden to replace/remove anything).
>> So please list the diff to let us fix that point if accurate.
>>
>>
>>> There have been plenty of smallish methods removed in e.g. EJB and
>>> servlet. But also in other specs. So we WILL need to go full scale. And I
>>> also expect more changes to come for JakartaEE9.
>>>
>>
>>
>> Ok, think it is your method removal ;).
>> It is not that accurate for this vote, both jars are not in the scope of
>> this vote.
>>
>> I agree on EE9 point and here we will just create the jar from scratch as
>> usual, with the right package directly, no ambiguity or discussion IMHO.
>>
>>
>>>
>>> EE8 is FINISHED. There is NO change!
>>>
>>
>> Does not mean we don't need to release the jar, please just have a look
>> to the versions of this thread (which is <1/6  of all specs), spec were
>> finished when we did 1.0 but we are at 1.4 for some jars so not a point for
>> me.
>>
>>
>>>
>>> All which happens is done in JakartaEE. And we have all the work done
>>> since a year?
>>> I could do a release of those jars today.
>>>
>>
>> If you can do all jakarta jars I'm happy to cancel this vote as
>> mentionned already, my goal was just to get jakarta artifacts for free (and
>> this is what this vote does) to enable the CDI-SE/JSON-B case which starts
>> to get pressure to be useable in jakarta namespace more than others.
>>
>>
>>> Also your list of specs is not final. There is quite a few missing.
>>>
>>
>> Not sure what you mean, I released the ones I announce for CDI SE +
>> JSON-B stacks.
>>
>>
>>>
>>> So why not release from here?
>>> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/
>>>
>>
>> Not sure what would be the point to create another branch, we can keep
>> specs/ still it is specs, no?
>>
>> However, I'm -1 to change the artifact id to contain jakarta. Worse case
>> we could do geronimo--api to try to simplify the naming, avoid a
>> 2-versions based convention and be less rude to end user + use a jpms
>> friendly default name (even if we put an automatic name it avoids issues in
>> some envs/ide).
>>
>>
>>>
>>> Actually I'd move this to
>>>
>>> http://svn.apache.org/repos/asf/geronimo/jakarta-specs/trunk
>>>
>>
>> If we would move anything I would try to use gitbox but can wait after
>> the first release which is, IMHO, the most urgent.
>>
>>
>>>
>>> and then do the release.
>>>
>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> Am 28.04.2020 um 07:59 schrieb Romain Manni-Bucau >> >:
>>>
>>> Hi everyone,
>>>
>>> Here is the vote for some of our spec with jakarta shades.
>>>
>>> Tags:
>>> -
>>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jcdi_2.0_spec-1.2/
>>>  (rev 1877103)
>>> -
>>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-annotation_1.3_spec-1.3/
>>>  (rev
>>> 1877106)
>>> -
>>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-atinject_1.0_spec-1.2/
>>>  (rev
>>> 1877109)
>>> -
>>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-interceptor_1.2_spec-1.2/
>>>  (rev
>>> 1877112)
>>> -
>>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-json_1.1_spec-1.4/
>>>  (rev
>>> 1877115)

Re: [VOTE] Apache Geronimo Specs JCDI_2.0 1.2, Annotation_1.3 1.3, AtInject_1.0 1.2, Interceptor_1.2 1.2, JSONP_1.1 1.4, JSONB_1.0 1.3

2020-05-04 Thread Romain Manni-Bucau 
My own +1

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



Le lun. 4 mai 2020 à 09:00, Mark Struberg  a écrit :

> +1 because it allows us to more forward quickly.
>
> Over the mid- and long-term we will need a separate branch/project I fear.
> There are already slight differences in e.g. EJB, and a few other specs.
> But for now this is sufficient enough for people to start playing with.
> Just keep in mind that we will finally change artifact coordinates!
>
> LieGrue,
> strub
>
>
> Am 28.04.2020 um 19:28 schrieb Romain Manni-Bucau :
>
>
>
> Le mar. 28 avr. 2020 à 18:25, Mark Struberg  a écrit :
>
>> As explained in the other thread:
>>
>> What is the difference between the various specs and their previous
>> versions?
>> Afaict the only difference is jakartaEE, and we WILL  NOT MANAGE to do
>> all via simple replacement. This is an absolute dead end.
>>
>
> Mark, you keep saying that but each time I ask for a proof of that you
> never answer.
> Most of the spec are 1-1 (it was the deal of jakartaee8 and some spec had
> been forbidden to replace/remove anything).
> So please list the diff to let us fix that point if accurate.
>
>
>> There have been plenty of smallish methods removed in e.g. EJB and
>> servlet. But also in other specs. So we WILL need to go full scale. And I
>> also expect more changes to come for JakartaEE9.
>>
>
>
> Ok, think it is your method removal ;).
> It is not that accurate for this vote, both jars are not in the scope of
> this vote.
>
> I agree on EE9 point and here we will just create the jar from scratch as
> usual, with the right package directly, no ambiguity or discussion IMHO.
>
>
>>
>> EE8 is FINISHED. There is NO change!
>>
>
> Does not mean we don't need to release the jar, please just have a look to
> the versions of this thread (which is <1/6  of all specs), spec were
> finished when we did 1.0 but we are at 1.4 for some jars so not a point for
> me.
>
>
>>
>> All which happens is done in JakartaEE. And we have all the work done
>> since a year?
>> I could do a release of those jars today.
>>
>
> If you can do all jakarta jars I'm happy to cancel this vote as
> mentionned already, my goal was just to get jakarta artifacts for free (and
> this is what this vote does) to enable the CDI-SE/JSON-B case which starts
> to get pressure to be useable in jakarta namespace more than others.
>
>
>> Also your list of specs is not final. There is quite a few missing.
>>
>
> Not sure what you mean, I released the ones I announce for CDI SE + JSON-B
> stacks.
>
>
>>
>> So why not release from here?
>> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/
>>
>
> Not sure what would be the point to create another branch, we can keep
> specs/ still it is specs, no?
>
> However, I'm -1 to change the artifact id to contain jakarta. Worse case
> we could do geronimo--api to try to simplify the naming, avoid a
> 2-versions based convention and be less rude to end user + use a jpms
> friendly default name (even if we put an automatic name it avoids issues in
> some envs/ide).
>
>
>>
>> Actually I'd move this to
>>
>> http://svn.apache.org/repos/asf/geronimo/jakarta-specs/trunk
>>
>
> If we would move anything I would try to use gitbox but can wait after the
> first release which is, IMHO, the most urgent.
>
>
>>
>> and then do the release.
>>
>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> Am 28.04.2020 um 07:59 schrieb Romain Manni-Bucau > >:
>>
>> Hi everyone,
>>
>> Here is the vote for some of our spec with jakarta shades.
>>
>> Tags:
>> -
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jcdi_2.0_spec-1.2/
>>  (rev 1877103)
>> -
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-annotation_1.3_spec-1.3/
>>  (rev
>> 1877106)
>> -
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-atinject_1.0_spec-1.2/
>>  (rev
>> 1877109)
>> -
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-interceptor_1.2_spec-1.2/
>>  (rev
>> 1877112)
>> -
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-json_1.1_spec-1.4/
>>  (rev
>> 1877115)
>> -
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsonb_1.0_spec-1.3/
>>  (rev
>> 1877118)
>> Dist area:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1124
>> Staging repo: https://dist.apache.org/repos/dist/dev/geronimo/specs/
>> My key is still the same.
>>
>> Please vote:
>>
>> [ ] +1 release it
>> [ ] -1 dont' release it ${cause}
>>
>> Vote is open for 3 days or until we get enough bindings as usual.
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  |

Re: [VOTE] Apache Geronimo Specs JCDI_2.0 1.2, Annotation_1.3 1.3, AtInject_1.0 1.2, Interceptor_1.2 1.2, JSONP_1.1 1.4, JSONB_1.0 1.3

2020-05-04 Thread Mark Struberg 
+1 because it allows us to more forward quickly.

Over the mid- and long-term we will need a separate branch/project I fear. 
There are already slight differences in e.g. EJB, and a few other specs.
But for now this is sufficient enough for people to start playing with. 
Just keep in mind that we will finally change artifact coordinates!

LieGrue,
strub


> Am 28.04.2020 um 19:28 schrieb Romain Manni-Bucau :
> 
> 
> 
> Le mar. 28 avr. 2020 à 18:25, Mark Struberg  > a écrit :
> As explained in the other thread:
> 
> What is the difference between the various specs and their previous versions?
> Afaict the only difference is jakartaEE, and we WILL  NOT MANAGE to do all 
> via simple replacement. This is an absolute dead end. 
> 
> Mark, you keep saying that but each time I ask for a proof of that you never 
> answer.
> Most of the spec are 1-1 (it was the deal of jakartaee8 and some spec had 
> been forbidden to replace/remove anything).
> So please list the diff to let us fix that point if accurate.
>  
> There have been plenty of smallish methods removed in e.g. EJB and servlet. 
> But also in other specs. So we WILL need to go full scale. And I also expect 
> more changes to come for JakartaEE9.
> 
> 
> Ok, think it is your method removal ;).
> It is not that accurate for this vote, both jars are not in the scope of this 
> vote.
> 
> I agree on EE9 point and here we will just create the jar from scratch as 
> usual, with the right package directly, no ambiguity or discussion IMHO.
>  
> 
> EE8 is FINISHED. There is NO change!
> 
> Does not mean we don't need to release the jar, please just have a look to 
> the versions of this thread (which is <1/6  of all specs), spec were finished 
> when we did 1.0 but we are at 1.4 for some jars so not a point for me.
>  
> 
> All which happens is done in JakartaEE. And we have all the work done since a 
> year?
> I could do a release of those jars today.
> 
> If you can do all jakarta jars I'm happy to cancel this vote as mentionned 
> already, my goal was just to get jakarta artifacts for free (and this is what 
> this vote does) to enable the CDI-SE/JSON-B case which starts to get pressure 
> to be useable in jakarta namespace more than others.
>  
> Also your list of specs is not final. There is quite a few missing.
> 
> Not sure what you mean, I released the ones I announce for CDI SE + JSON-B 
> stacks.
>  
> 
> So why not release from here?
> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ 
> 
> 
> Not sure what would be the point to create another branch, we can keep specs/ 
> still it is specs, no?
> 
> However, I'm -1 to change the artifact id to contain jakarta. Worse case we 
> could do geronimo--api to try to simplify the naming, avoid a 
> 2-versions based convention and be less rude to end user + use a jpms 
> friendly default name (even if we put an automatic name it avoids issues in 
> some envs/ide).
>  
> 
> Actually I'd move this to 
> 
> http://svn.apache.org/repos/asf/geronimo/jakarta-specs/trunk 
> 
> 
> If we would move anything I would try to use gitbox but can wait after the 
> first release which is, IMHO, the most urgent.
>  
> 
> and then do the release. 
> 
> 
> LieGrue,
> strub
> 
> 
> 
>> Am 28.04.2020 um 07:59 schrieb Romain Manni-Bucau > >:
>> 
>> Hi everyone,
>> 
>> Here is the vote for some of our spec with jakarta shades.
>> 
>> Tags:
>> - 
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jcdi_2.0_spec-1.2/
>>  
>> 
>>  (rev 1877103)
>> - 
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-annotation_1.3_spec-1.3/
>>  
>> 
>>  (rev 1877106)
>> - 
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-atinject_1.0_spec-1.2/
>>  
>> 
>>  (rev 1877109)
>> - 
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-interceptor_1.2_spec-1.2/
>>  
>> 
>>  (rev 1877112)
>> - 
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-json_1.1_spec-1.4/
>>  
>> 
>>  (rev 1877115)
>> - 
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsonb_1.0_spec-1.3/
>>  
>> 
>>  (rev 1877118)
>> Dist area: 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1124 
>> 
>> Staging repo: