Re: [VOTE] Release geronimo-openapi-1.0.13

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 16 oct. 2020 à 15:20, Mark Struberg  a écrit :
> 
> 
> 
> Hi!
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/ 
> 
> 
> 
> 
> source jars can be found at
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/org/apache/geronimo/geronimo-openapi/1.0.13/
>  
> 
> sha1 074ecb59b23e5a8550126e360dc244c75bd5dc6d
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> Here is my own one for the start.
> +1
> 
> txs and LieGrue,
> strub

Re: [VOTE] Release geronimo-openapi-1.0.13

[Daniel Cunha]

+1

Em sex., 16 de out. de 2020 às 11:19, Francois Papon <
francois.pa...@openobject.fr> escreveu:

> +1 (non-binding)
>
> regards,
>
> François
> fpa...@apache.org
>
> Le 16/10/2020 à 15:20, Mark Struberg a écrit :
> >
> >
> > Hi!
> >
> > Here is the staging repo
> >
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/
> > <
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/
> >
> >
> >
> >
> > source jars can be found at
> >
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/org/apache/geronimo/geronimo-openapi/1.0.13/
> > <
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/org/apache/geronimo/geronimo-openapi/1.0.13/
> >
> > sha1 074ecb59b23e5a8550126e360dc244c75bd5dc6d
> >
> > Please VOTE
> >
> > [+1] go ship it
> > [+0] meh, don't care
> > [-1] stop, there is a ${showstopper}
> >
> > The VOTE is open for 72h
> >
> > Here is my own one for the start.
> > +1
> >
> > txs and LieGrue,
> > strub
>


-- 
Daniel "soro" Cunha
https://twitter.com/dvlc_

Re: [VOTE] Release geronimo-openapi-1.0.13

[Francois Papon]

+1 (non-binding)

regards,

François
fpa...@apache.org

Le 16/10/2020 à 15:20, Mark Struberg a écrit :
>
>
> Hi!
>
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/
> 
>
>
>
> source jars can be found at
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/org/apache/geronimo/geronimo-openapi/1.0.13/
> 
> sha1 074ecb59b23e5a8550126e360dc244c75bd5dc6d
>
> Please VOTE
>
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
>
> The VOTE is open for 72h
>
> Here is my own one for the start.
> +1
>
> txs and LieGrue,
> strub

Re: [VOTE] Release geronimo-openapi-1.0.13

[Romain Manni-Bucau]

+1

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



Le ven. 16 oct. 2020 à 15:23, Raymond Auge  a
écrit :

> +1
>
> - Ray
>
> On Fri, Oct 16, 2020 at 9:21 AM Mark Struberg  wrote:
>
>>
>>
>> Hi!
>>
>> Here is the staging repo
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/
>>
>>
>>
>> source jars can be found at
>>
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/org/apache/geronimo/geronimo-openapi/1.0.13/
>> sha1 074ecb59b23e5a8550126e360dc244c75bd5dc6d
>>
>> Please VOTE
>>
>> [+1] go ship it
>> [+0] meh, don't care
>> [-1] stop, there is a ${showstopper}
>>
>> The VOTE is open for 72h
>>
>> Here is my own one for the start.
>> +1
>>
>> txs and LieGrue,
>> strub
>>
>
>
> --
> *Raymond Augé* (@rotty3000)
> Senior Software Architect *Liferay, Inc.* (@Liferay)
> OSGi Fellow
>

Re: [VOTE] Release geronimo-openapi-1.0.13

[Raymond Auge]

+1

- Ray

On Fri, Oct 16, 2020 at 9:21 AM Mark Struberg  wrote:

>
>
> Hi!
>
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/
>
>
>
> source jars can be found at
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/org/apache/geronimo/geronimo-openapi/1.0.13/
> sha1 074ecb59b23e5a8550126e360dc244c75bd5dc6d
>
> Please VOTE
>
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
>
> The VOTE is open for 72h
>
> Here is my own one for the start.
> +1
>
> txs and LieGrue,
> strub
>


-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow

[VOTE] Release geronimo-openapi-1.0.13

[Mark Struberg]

Hi!

Here is the staging repo
https://repository.apache.org/content/repositories/orgapachegeronimo-1132/ 




source jars can be found at
https://repository.apache.org/content/repositories/orgapachegeronimo-1132/org/apache/geronimo/geronimo-openapi/1.0.13/
 

sha1 074ecb59b23e5a8550126e360dc244c75bd5dc6d

Please VOTE

[+1] go ship it
[+0] meh, don't care
[-1] stop, there is a ${showstopper}

The VOTE is open for 72h

Here is my own one for the start.
+1

txs and LieGrue,
strub

Re: Fork some of our MP impls

[Romain Manni-Bucau]

Just to comfort this thread, openapi 2.RC breaks API and behaviors too +
can be worth having a POJO mapping to simplify the JSON usage (and
reusability since it avoids customizations and custom, provider specific
factories).
So overall I think that rather than sticking to Microprofile which does not
go anywhere we should keep our codebase as something independent, stable
and reusable.

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



Le mar. 22 sept. 2020 à 20:53, Francois Papon 
a écrit :

> No problem, I don't care so much about the name too ;)
>
> regards,
>
> Françoisfpa...@apache.org
>
> Le 22/09/2020 à 20:01, Romain Manni-Bucau a écrit :
>
> Hmm, both are not linked this way (more the opposite ;)).
> Why not kat (cat for kubernetes, read somewhere everybody loves cats)? ;)
>
> Btw i dont care much of the name while it can last but Id like some other
> opinion if possible (even negative) - otherwise it can be done at github ;).
>
> Le mar. 22 sept. 2020 à 19:34, Francois Papon <
> francois.pa...@openobject.fr> a écrit :
>
>> May be we can call it "excalibur" as we already have "arthur" :)
>>
>> regards,
>>
>> Françoisfpa...@apache.org
>>
>> Le 21/09/2020 à 21:05, Romain Manni-Bucau a écrit :
>>
>> Up, any issue to create a geronimo-stack (happy to get a better name)
>> project?
>>
>>
>> Le lun. 10 août 2020 à 08:47, Romain Manni-Bucau 
>> a écrit :
>>
>>> Small up, guess it is still holidays so will wait for a few more weeks
>>> to try to get more feedbacks before doing anything.
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github
>>>  | LinkedIn
>>>  | Book
>>> 
>>>
>>>
>>> Le ven. 31 juil. 2020 à 09:16, Romain Manni-Bucau 
>>> a écrit :
>>>
 Makes sense, thanks François

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


 Le ven. 31 juil. 2020 à 09:15, Francois Papon <
 francois.pa...@openobject.fr> a écrit :

> Hi Romain,
>
> I think the config spec is interesting and could be add to the list.
>
> regards,
>
> Françoisfpa...@apache.org
>
> Le 31/07/2020 à 08:34, Romain Manni-Bucau a écrit :
>
> Hi everyone,
>
> After some years of MP I think it is not a safe enough technology for
> long term applications - i.e. maintained and evolved, not just
> developed for 6 months.
> The main drawback is that it changes and breaks too often and from my
> understanding it is not likely about to change (what I understood is it
> will likely be worse and can even import vendor/library API in the spec 
> API
> as it had been done for tracing one).
>
> The most common requirements are, IMHO:
>
> 1. health
> 2. metrics (gauge+counter+openmetrics exporter, others are fancy
> things)
> 3. tracing
>
> maybe jwt-auth even if less sure.
>
> Therefore I wonder if we want to fork our own MP impl to provide these
> 3 specs simplified versions with a stable API.
> I envision a single repo with the 3 api/impl.
>
> wdyt?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>

Re: jira ticket mess

[Mark Struberg]

sounds like a plan!


> Am 16.10.2020 um 13:49 schrieb Romain Manni-Bucau :
> 
> Hi Mark,
> 
> We put the project in the version, works not back and enables filtering as 
> well as we would have subprojects. It also avoids to have to request new 
> component each time we add a project so think it is a good compromise for us.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 
> 
> Le ven. 16 oct. 2020 à 13:39, Jean-Baptiste Onofre  > a écrit :
> Hi,
> 
> What about generalizing use of fix version containing the "target" project 
> (and we do for openapi or metrics) ?
> 
> I think both component + fix version would be enough to clearly identify 
> release content/release notes.
> 
> Regards
> JB
> 
> 
> > Le 16 oct. 2020 à 13:34, Mark Struberg  > > a écrit :
> > 
> > hi folks!
> > 
> > Geronimo is an umbrella project. We have tons of tickets, but we actually 
> > cannot make much sense of it tracking wise as the versions in JIRA is per 
> > project and not per module.
> > 
> > That means if we do a release, we do not really have a clean track about 
> > what actually got fixed, right?
> > 
> > Otoh if we would do a distinct JIRA project per actual release artifact, 
> > then we would have 100++ different jira projecs? Just think about all the 
> > many dozen geronimo-spec jars.
> > 
> > How do we want to cope with this in the future? Does anyone have an idea 
> > how this can be improved?
> > 
> > txs and LieGrue,
> > strub
> > 
> 

Re: jira ticket mess

[Romain Manni-Bucau]

Hi Mark,

We put the project in the version, works not back and enables filtering as
well as we would have subprojects. It also avoids to have to request new
component each time we add a project so think it is a good compromise for
us.

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



Le ven. 16 oct. 2020 à 13:39, Jean-Baptiste Onofre  a
écrit :

> Hi,
>
> What about generalizing use of fix version containing the "target" project
> (and we do for openapi or metrics) ?
>
> I think both component + fix version would be enough to clearly identify
> release content/release notes.
>
> Regards
> JB
>
>
> > Le 16 oct. 2020 à 13:34, Mark Struberg  a écrit :
> >
> > hi folks!
> >
> > Geronimo is an umbrella project. We have tons of tickets, but we
> actually cannot make much sense of it tracking wise as the versions in JIRA
> is per project and not per module.
> >
> > That means if we do a release, we do not really have a clean track about
> what actually got fixed, right?
> >
> > Otoh if we would do a distinct JIRA project per actual release artifact,
> then we would have 100++ different jira projecs? Just think about all the
> many dozen geronimo-spec jars.
> >
> > How do we want to cope with this in the future? Does anyone have an idea
> how this can be improved?
> >
> > txs and LieGrue,
> > strub
> >
>
>

Re: jira ticket mess

[Jean-Baptiste Onofre]

Hi,

What about generalizing use of fix version containing the "target" project (and 
we do for openapi or metrics) ?

I think both component + fix version would be enough to clearly identify 
release content/release notes.

Regards
JB


> Le 16 oct. 2020 à 13:34, Mark Struberg  a écrit :
> 
> hi folks!
> 
> Geronimo is an umbrella project. We have tons of tickets, but we actually 
> cannot make much sense of it tracking wise as the versions in JIRA is per 
> project and not per module.
> 
> That means if we do a release, we do not really have a clean track about what 
> actually got fixed, right?
> 
> Otoh if we would do a distinct JIRA project per actual release artifact, then 
> we would have 100++ different jira projecs? Just think about all the many 
> dozen geronimo-spec jars.
> 
> How do we want to cope with this in the future? Does anyone have an idea how 
> this can be improved?
> 
> txs and LieGrue,
> strub
> 

jira ticket mess

[Mark Struberg]

hi folks!

Geronimo is an umbrella project. We have tons of tickets, but we actually 
cannot make much sense of it tracking wise as the versions in JIRA is per 
project and not per module.

That means if we do a release, we do not really have a clean track about what 
actually got fixed, right?

Otoh if we would do a distinct JIRA project per actual release artifact, then 
we would have 100++ different jira projecs? Just think about all the many dozen 
geronimo-spec jars.

How do we want to cope with this in the future? Does anyone have an idea how 
this can be improved?

txs and LieGrue,
strub

[GitHub] [geronimo-openapi] struberg commented on pull request #4: GERONIMO-6670 - fixing text/html issue and tests (snake dependency wa…

[GitBox]

struberg commented on pull request #4:
URL: https://github.com/apache/geronimo-openapi/pull/4#issuecomment-709985541


   This ticket got resolved afaict, right? Please reopen if not!



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] struberg closed pull request #4: GERONIMO-6670 - fixing text/html issue and tests (snake dependency wa…

[GitBox]

struberg closed pull request #4:
URL: https://github.com/apache/geronimo-openapi/pull/4


   



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

Re: [VOTE] Release geronimo-jcdi_2.0 spec api version 1.3

[Francois Papon]

+1 (non-binding)

regards,

François
fpa...@apache.org

Le 15/10/2020 à 19:40, Mark Struberg a écrit :
> Hi!
>
> I want to call a VOTE on releasing 
> geronimo-jcdi_2.0 1.3
>
> The staging repo is:
> _https://repository.apache.org/content/repositories/orgapachegeronimo-1130/
> _
>
> source jars can be found
> _https://repository.apache.org/content/repositories/orgapachegeronimo-1130/org/apache/geronimo/specs/geronimo-jcdi_2.0_spec/1.3/
> _
> sha1 3b12c73bef67722578fa68874074879fd0473748
>
>
> Please VOTE
>
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
>
> The VOTE is open for 72h
>
> Here is my own one for the start.
> +1
>
> txs and LieGrue,
> strub
>

Re: [VOTE] Release geronimo-jcdi_1.0 and 1.1 spec jars

[Francois Papon]

+1 (non-binding)

regards,

François
fpa...@apache.org

Le 15/10/2020 à 19:37, Mark Struberg a écrit :
> Hi!
>
> I want to call a VOTE on releasing 
> geronimo-jcdi_1.0-1.1 and
> geronimo-jcdi_1.1-1.1
>
> The staging repo is:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1129/
> 
>
> source jars can be found
> https://repository.apache.org/content/repositories/orgapachegeronimo-1129/org/apache/geronimo/specs/geronimo-jcdi_1.0_spec/1.1/
> 
> sha1 54f20c989d20cb56363c88b9884376821b6b0a4e
>
> and 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1129/org/apache/geronimo/specs/geronimo-jcdi_1.1_spec/1.1/
> 
> sha1 8ef821f792a6d1286edf719774e8ea32ded145b6
>
> Please VOTE
>
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
>
> The VOTE is open for 72h
>
> Here is my own one for the start.
> +1
>
> txs and LieGrue,
> strub
>
>

Re: [VOTE] geronimo jsonp, jsonb, security, validation releases

[Francois Papon]

+1 (non-binding)

regards,

François
fpa...@apache.org

Le 15/10/2020 à 22:38, Mark Struberg a écrit :
> Hi!
>
> I want to call a VOTE on releasing 
>
>
> geronimo-json_1.1_spec-1.5
> geronimo-jsonb_1.0_spec-1.4
> geronimo-security_1.0_spec-1.1
> geronimo-validation_2.0_spec-1.1
>
> The only difference to the previous releases is the addition of jpms
> module names via manifest by updating to genesis-flava8-2.4.
> I did run the release with Java8. Have fun!
>
>
> The staging repo is:
> _https://repository.apache.org/content/repositories/orgapachegeronimo-1131/
> _
>
>
> Please VOTE
>
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
>
> The VOTE is open for 72h
>
> Here is my own one for the start.
> +1
>
> txs and LieGrue,
> strub