Re: DISCUSS geronimo-security_1.0_spec content unclear

[David Blevins]

> On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau  wrote:
> 
> If we still can't reuse jakata artifacts (their license is ok and there is no 
> impl reference inside so we should just use them, right?) it sounds natural

This is my current thinking as well; maintain apis that are impls, use the EPL 
version otherwise.

We do have a handful of EPL dependencies, such as ECJ which Tomcat itself uses. 
 Also as more projects like CXF switch over using the Jakarta versions, our 
excludes just get harder to manage.


-David

> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro  
> a écrit :
> Hi all,
> 
> I was digging into some other specifications and see what would pass Jakarta 
> TCK and realized that geronimo-security_1.0_spec content actually mixes 2 
> specifications.
> 
> https://github.com/eclipse-ee4j/security-api
> 
> and 
> 
> https://github.com/eclipse-ee4j/jaspic
> 
> I thought the initial intent was to create a specific artifact per 
> specification.
> Mixing them is a bit annoying from a certification perspective.
> It's also not clean because in Tomcat for instance, there is already jaspic 
> API so it becomes a duplicate.
> 
> Would it be possible to split them up in 2 artifacts?
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com

Re: [VOTE] Release geronimo-security_1.0_spec API

[Cesar Hernandez]

+1

El mar., 3 sept. 2019 a las 11:43, Romain Manni-Bucau (<
rmannibu...@gmail.com>) escribió:

> +1
>
> Le mar. 3 sept. 2019 à 19:29, Raymond Auge  a
> écrit :
>
>> +1
>>
>> - Ray
>>
>> On Tue, Sep 3, 2019 at 11:25 AM Jean-Louis MONTEIRO 
>> wrote:
>>
>>>
>>> Hi!
>>>
>>> I’d like to call a VOTE on the geronimo-security_1.0_spec-1.0.jar.
>>> This is an API which implements the Security API JSR-375 1.0
>>> specification.
>>>
>>> Here is the staging repo
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1110
>>>
>>> And the source jar which is voted on
>>>
>>> https://repository.apache.org/service/local/repositories/orgapachegeronimo-1110/content/org/apache/geronimo/specs/geronimo-security_1.0_spec/1.0/geronimo-security_1.0_spec-1.0-source-release.zip
>>>
>>>
>>> My key can be found at
>>> https://svn.apache.org/repos/asf/geronimo/KEYS
>>>
>>> please VOTE
>>> [+1] all fine, ship it
>>> [+0] don't care
>>> [-1] stop, because ${reason}
>>>
>>> The VOTE is open for 72h.
>>>
>>> --
>>> Jean-Louis
>>>
>>
>>
>> --
>> *Raymond Augé* 
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>>  (@Liferay)
>>
>

-- 
Atentamente:
César Hernández.

Re: [VOTE] Release geronimo-security_1.0_spec API

[Romain Manni-Bucau]

+1

Le mar. 3 sept. 2019 à 19:29, Raymond Auge  a
écrit :

> +1
>
> - Ray
>
> On Tue, Sep 3, 2019 at 11:25 AM Jean-Louis MONTEIRO 
> wrote:
>
>>
>> Hi!
>>
>> I’d like to call a VOTE on the geronimo-security_1.0_spec-1.0.jar.
>> This is an API which implements the Security API JSR-375 1.0
>> specification.
>>
>> Here is the staging repo
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1110
>>
>> And the source jar which is voted on
>>
>> https://repository.apache.org/service/local/repositories/orgapachegeronimo-1110/content/org/apache/geronimo/specs/geronimo-security_1.0_spec/1.0/geronimo-security_1.0_spec-1.0-source-release.zip
>>
>>
>> My key can be found at
>> https://svn.apache.org/repos/asf/geronimo/KEYS
>>
>> please VOTE
>> [+1] all fine, ship it
>> [+0] don't care
>> [-1] stop, because ${reason}
>>
>> The VOTE is open for 72h.
>>
>> --
>> Jean-Louis
>>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
>

Re: [VOTE] Release geronimo-security_1.0_spec API

[Raymond Auge]

+1

- Ray

On Tue, Sep 3, 2019 at 11:25 AM Jean-Louis MONTEIRO 
wrote:

>
> Hi!
>
> I’d like to call a VOTE on the geronimo-security_1.0_spec-1.0.jar.
> This is an API which implements the Security API JSR-375 1.0 specification
> .
>
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1110
>
> And the source jar which is voted on
>
> https://repository.apache.org/service/local/repositories/orgapachegeronimo-1110/content/org/apache/geronimo/specs/geronimo-security_1.0_spec/1.0/geronimo-security_1.0_spec-1.0-source-release.zip
>
>
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
>
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
>
> The VOTE is open for 72h.
>
> --
> Jean-Louis
>


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

Re: Java EE 8 versions of APIs

[David Blevins]

See this note on our activation thread.  Long story short, our version 1.1 is 
legitimate and the exact version expected for Java EE 8 on Java 8.

 - 
https://lists.apache.org/thread.html/89f81b0584dffca7d979a4fdedc6fe7b4f3c547848b0159b1702857e@

On JavaMail, my recommendation would be to update asap, but not hold up the 
TomEE 8.0.0 final release.

IMHO, we should try to be vote-ready on Friday.  If we can get it done in that 
time, cool.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Sep 3, 2019, at 8:48 AM, Jean-Louis Monteiro  
> wrote:
> 
> Trying to pull this message up in the list.
> 
> If we want to release Apache TomEE 8.0.0 before CodeOne, we need JavaMail,
> Activation and some others.
> For the others, I think I managed to get them up for vote and ready.
> 
> For Activation and JavaMail it's also an implementation so there is more
> work involved and I am not sure we can get it done by CodeOne.
> Of course it's not a good reason, but I still want to revive this topic so
> we can decide all together how we want to proceed.
> 
> Do we update/create our specs in Geronimo?
> Do we use the eclipse jars?
> 
> thoughts
> 
> 
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Thu, Aug 15, 2019 at 5:53 AM David Blevins 
> wrote:
> 
>>> On Aug 14, 2019, at 2:05 AM, Alex The Rocker 
>> wrote:
>>> 
>>> Okay; for EDL I see it's compatible with Apache licensing, but
>>> strangely, JAXB license does not look like an EDL:
>>> https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
>>> 
>>> Am I mistaking or this is actually "cheesy" ?
>> 
>> I pulled down the official text here and did a quick reformat to match it
>> to the LICENSE.md
>> 
>> - https://www.eclipse.org/org/documents/edl-v10.php
>> 
>> Sans the copyright statement, both came out identical in a diff, so we
>> appear good.
>> 
>> We will want to make sure our NOTICE file does contain the copyright
>> statement, so that is a definitely good catch.
>> 
>> 
>> -David
>> 
>>> Le mer. 14 août 2019 à 10:37, David Blevins  a
>> écrit :
 
> On Aug 14, 2019, at 1:23 AM, Alex The Rocker 
>> wrote:
> 
> Hello,
> 
> How about JAXB which is not EPL but EDL 1.0 ?
> (see https://github.com/eclipse-ee4j/jaxb-api/tree/2.3.2)
 
 EDL is an approved license.  Here's the complete naughty and nice list
>> as it where :)
 
 - https://apache.org/legal/resolved.html
 
 The interesting thing about jaxb-api is there is only one
>> implementation in the world and it is also EDL and no longer included in
>> the JVM.  If we typed in the API, 98% of the other JAXB code we ship would
>> still be EDL.
 
 
 -David
 
> Le mer. 14 août 2019 à 10:16, David Blevins 
>> a écrit :
>> 
>> This is really the better thread to talk about how to handle the gaps
>> in our Java EE 8 APIs and support.
>> 
>> As noted, there is not license victory to be won.  We have had EPL
>> and CDDL dependencies since v1.0 in 2011.
>> 
>> From a Geronimo perspective, we typed in the APIs and created all
>> those spec jars because there were no open source options that weren't the
>> JBoss GPL versions.  GlassFish didn't exist yet.  When GlassFish came
>> about, we kept up the practice largely out of habit.  We did have an
>> unavoidable CDDL via the xml schemas and JAXB RI, so our licensing victory
>> wasn't quite there.
>> 
>> This is really a resources and timeline issue.
>> 
>> Some of these specs are actually implementations, specifically:
>> 
>> - JavaMail 1.6
>> - JACC 1.6
>> - Activation 1.2
>> 
>> If we decide we want the Geronimo versions to be upgraded
>> (implemented) and this is important for TomEE 8, we should expect that to
>> ship sometime 2020.
>> 
>> 
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>> 
>>> On Aug 13, 2019, at 12:10 AM, David Blevins 
>> wrote:
>>> 
>>> I did a small gap-analysis of where we're still short on Java EE 8
>> APIs from the perspective of our javaee-api jar:
>>> 
>>> - https://issues.apache.org/jira/browse/TOMEE-2620
>>> 
>>> Specific callouts are these APIs are also implementations, so
>> switching to the equivalent Jakarta version also gains a compliant
>> implementation:
>>> 
>>> - javax.activation 1.1 vs 1.2
>>> - javax.security.jacc 1.4 vs 1.6
>>> - javax.mail 1.5 vs 1.6
>>> 
>>> This one is a flaw in my reporting, it's included in Tomcat:
>>> 
>>> - javax.security.auth.message 1.0 vs 1.1 (JASPIC)
>>> 
>>> We should likely use the exact version cxf requires of this:
>>> 
>>> - javax.xml.ws 2.2 vs 2.3 (JAX-WS)
>>> 
>>> These we will likely not be able to change as the corresponding
>> implementations aren't there:
>>> 
>>> - javax.enterprise.concurrent 1.0 vs 1.1
>>> - javax.resourc

Re: Java EE 8 versions of APIs

[Jean-Louis Monteiro]

Trying to pull this message up in the list.

If we want to release Apache TomEE 8.0.0 before CodeOne, we need JavaMail,
Activation and some others.
For the others, I think I managed to get them up for vote and ready.

For Activation and JavaMail it's also an implementation so there is more
work involved and I am not sure we can get it done by CodeOne.
Of course it's not a good reason, but I still want to revive this topic so
we can decide all together how we want to proceed.

Do we update/create our specs in Geronimo?
Do we use the eclipse jars?

thoughts



--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Thu, Aug 15, 2019 at 5:53 AM David Blevins 
wrote:

> > On Aug 14, 2019, at 2:05 AM, Alex The Rocker 
> wrote:
> >
> > Okay; for EDL I see it's compatible with Apache licensing, but
> > strangely, JAXB license does not look like an EDL:
> > https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
> >
> > Am I mistaking or this is actually "cheesy" ?
>
> I pulled down the official text here and did a quick reformat to match it
> to the LICENSE.md
>
>  - https://www.eclipse.org/org/documents/edl-v10.php
>
> Sans the copyright statement, both came out identical in a diff, so we
> appear good.
>
> We will want to make sure our NOTICE file does contain the copyright
> statement, so that is a definitely good catch.
>
>
> -David
>
> > Le mer. 14 août 2019 à 10:37, David Blevins  a
> écrit :
> >>
> >>> On Aug 14, 2019, at 1:23 AM, Alex The Rocker 
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> How about JAXB which is not EPL but EDL 1.0 ?
> >>> (see https://github.com/eclipse-ee4j/jaxb-api/tree/2.3.2)
> >>
> >> EDL is an approved license.  Here's the complete naughty and nice list
> as it where :)
> >>
> >> - https://apache.org/legal/resolved.html
> >>
> >> The interesting thing about jaxb-api is there is only one
> implementation in the world and it is also EDL and no longer included in
> the JVM.  If we typed in the API, 98% of the other JAXB code we ship would
> still be EDL.
> >>
> >>
> >> -David
> >>
> >>> Le mer. 14 août 2019 à 10:16, David Blevins 
> a écrit :
> 
>  This is really the better thread to talk about how to handle the gaps
> in our Java EE 8 APIs and support.
> 
>  As noted, there is not license victory to be won.  We have had EPL
> and CDDL dependencies since v1.0 in 2011.
> 
>  From a Geronimo perspective, we typed in the APIs and created all
> those spec jars because there were no open source options that weren't the
> JBoss GPL versions.  GlassFish didn't exist yet.  When GlassFish came
> about, we kept up the practice largely out of habit.  We did have an
> unavoidable CDDL via the xml schemas and JAXB RI, so our licensing victory
> wasn't quite there.
> 
>  This is really a resources and timeline issue.
> 
>  Some of these specs are actually implementations, specifically:
> 
>  - JavaMail 1.6
>  - JACC 1.6
>  - Activation 1.2
> 
>  If we decide we want the Geronimo versions to be upgraded
> (implemented) and this is important for TomEE 8, we should expect that to
> ship sometime 2020.
> 
> 
>  --
>  David Blevins
>  http://twitter.com/dblevins
>  http://www.tomitribe.com
> 
> > On Aug 13, 2019, at 12:10 AM, David Blevins 
> wrote:
> >
> > I did a small gap-analysis of where we're still short on Java EE 8
> APIs from the perspective of our javaee-api jar:
> >
> > - https://issues.apache.org/jira/browse/TOMEE-2620
> >
> > Specific callouts are these APIs are also implementations, so
> switching to the equivalent Jakarta version also gains a compliant
> implementation:
> >
> > - javax.activation 1.1 vs 1.2
> > - javax.security.jacc 1.4 vs 1.6
> > - javax.mail 1.5 vs 1.6
> >
> > This one is a flaw in my reporting, it's included in Tomcat:
> >
> > - javax.security.auth.message 1.0 vs 1.1 (JASPIC)
> >
> > We should likely use the exact version cxf requires of this:
> >
> > - javax.xml.ws 2.2 vs 2.3 (JAX-WS)
> >
> > These we will likely not be able to change as the corresponding
> implementations aren't there:
> >
> > - javax.enterprise.concurrent 1.0 vs 1.1
> > - javax.resource 1.6 vs 1.7
> > - javax.transaction 1.2 vs 1.3 (JTA)
> >
> > If we ship TomEE 8.0 with just those three lagging APIs, that would
> be pretty good.  Shipping a final with 8 lagging libraries, less fantastic.
> >
> > What do people think about the potential upgrades?
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> >
> 
> >>
>
>

[VOTE] Release geronimo-security_1.0_spec API

[Jean-Louis MONTEIRO]

Hi!

I’d like to call a VOTE on the geronimo-security_1.0_spec-1.0.jar.
This is an API which implements the Security API JSR-375 1.0 specification.

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

And the source jar which is voted on
https://repository.apache.org/service/local/repositories/orgapachegeronimo-1110/content/org/apache/geronimo/specs/geronimo-security_1.0_spec/1.0/geronimo-security_1.0_spec-1.0-source-release.zip


My key can be found at
https://svn.apache.org/repos/asf/geronimo/KEYS

please VOTE
[+1] all fine, ship it
[+0] don't care
[-1] stop, because ${reason}

The VOTE is open for 72h.

-- 
Jean-Louis

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Jean-Louis Monteiro]

Ok I fixed the issue. Actually the spec module was clean but the bundle
configuration was not so we were badly including JASPIC dependencies.

I'll open up a VOTE for it

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Tue, Sep 3, 2019 at 4:49 PM Romain Manni-Bucau 
wrote:

> go ahead
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 3 sept. 2019 à 16:41, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> a écrit :
>
> > We can raise the issue at Jakarta
> >
> > Meanwhile, can I remove the jaspic api classes because they really don't
> > have anything to do in this spec jar
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Sep 3, 2019 at 4:37 PM Romain Manni-Bucau  >
> > wrote:
> >
> >> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity
> for
> >> us.
> >> That said it is good to reuse the same GAV for end users so we might ask
> >> jakarta to double license its api jars?
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >>
> >>
> >> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com>
> >> a écrit :
> >>
> >> > Yep that was the point.
> >> > So I was asking if we should do the same yes or not.
> >> >
> >> > That seems to be your opinion Romain.
> >> > Mark on the other end is having some doubts about the license.
> >> > --
> >> > Jean-Louis Monteiro
> >> > http://twitter.com/jlouismonteiro
> >> > http://www.tomitribe.com
> >> >
> >> >
> >> > On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >> > wrote:
> >> >
> >> >> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> >> >> jlmonte...@tomitribe.com>
> >> >> a écrit :
> >> >>
> >> >> > Thanks Romain. I'm fine with using Eclipse jars if from a legal
> >> point of
> >> >> > view, it works.
> >> >> > Otherwise, I'd like to split our spec jars.
> >> >> >
> >> >> > What about MicroProfile?
> >> >> >
> >> >>
> >> >> We already agreed to not redo the API and use microprofile jars.
> >> >>
> >> >>
> >> >> > It's the same license and we are using them in our MicroProfile
> >> >> > implementations.
> >> >> > --
> >> >> > Jean-Louis Monteiro
> >> >> > http://twitter.com/jlouismonteiro
> >> >> > http://www.tomitribe.com
> >> >> >
> >> >> >
> >> >> > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg
> >>  >> >> >
> >> >> > wrote:
> >> >> >
> >> >> >> depends what their license is. EPL is (weak) copyleft. Thus I
> would
> >> >> like
> >> >> >> to avoid exposing it downstream as api.
> >> >> >>
> >> >> >> LieGrue,
> >> >> >> strub
> >> >> >>
> >> >> >>
> >> >> >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> >> >> >> rmannibu...@gmail.com>:
> >> >> >> >
> >> >> >> > If we still can't reuse jakata artifacts (their license is ok
> and
> >> >> there
> >> >> >> is
> >> >> >> > no impl reference inside so we should just use them, right?) it
> >> >> sounds
> >> >> >> > natural
> >> >> >> >
> >> >> >> > Romain Manni-Bucau
> >> >> >> > @rmannibucau  |  Blog
> >> >> >> >  | Old Blog
> >> >> >> >  | Github <
> >> >> >> https://github.com/rmannibucau> |
> >> >> >> > LinkedIn  | Book
> >> >> >> > <
> >> >> >>
> >> >>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> >> >> jlmonte...@tomitribe.com>
> >> >> >> > a écrit :
> >> >> >> >
> >> >> >> >> Hi all,
> >> >> >> >>
> >> >> >> >> I was digging into some other specifications and see what would
> >> pass
> >> >> >> >> Jakarta TCK and realized that geronimo-security_1.0_spec
> content
> >> >> >> actually
> >> >> >> >> mixes 2 specifications.
> >> >> >> >>
> >> >> >> >> https://github.com/eclipse-ee4j/security-api
> >> >> >> >>
> >> >> >> >> and
> >> >> >> >>
> >> >> >> >> https://github.com/eclipse-ee4j/jaspic
> >> >> >> >>
> >> >> >> >> I thought the initial intent was to create a specific artifact
> >> per
> >> >> >> >> specification.
> >> >> >> >> Mixing them is a bit annoying from a certification perspective.
> >> >> >> >> It's also not clean because in Tomcat for instance, there is
> >> already
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

go ahead

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



Le mar. 3 sept. 2019 à 16:41, Jean-Louis Monteiro 
a écrit :

> We can raise the issue at Jakarta
>
> Meanwhile, can I remove the jaspic api classes because they really don't
> have anything to do in this spec jar
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Sep 3, 2019 at 4:37 PM Romain Manni-Bucau 
> wrote:
>
>> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity for
>> us.
>> That said it is good to reuse the same GAV for end users so we might ask
>> jakarta to double license its api jars?
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>> a écrit :
>>
>> > Yep that was the point.
>> > So I was asking if we should do the same yes or not.
>> >
>> > That seems to be your opinion Romain.
>> > Mark on the other end is having some doubts about the license.
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> >
>> > On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> >> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> >> jlmonte...@tomitribe.com>
>> >> a écrit :
>> >>
>> >> > Thanks Romain. I'm fine with using Eclipse jars if from a legal
>> point of
>> >> > view, it works.
>> >> > Otherwise, I'd like to split our spec jars.
>> >> >
>> >> > What about MicroProfile?
>> >> >
>> >>
>> >> We already agreed to not redo the API and use microprofile jars.
>> >>
>> >>
>> >> > It's the same license and we are using them in our MicroProfile
>> >> > implementations.
>> >> > --
>> >> > Jean-Louis Monteiro
>> >> > http://twitter.com/jlouismonteiro
>> >> > http://www.tomitribe.com
>> >> >
>> >> >
>> >> > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg
>> > >> >
>> >> > wrote:
>> >> >
>> >> >> depends what their license is. EPL is (weak) copyleft. Thus I would
>> >> like
>> >> >> to avoid exposing it downstream as api.
>> >> >>
>> >> >> LieGrue,
>> >> >> strub
>> >> >>
>> >> >>
>> >> >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
>> >> >> rmannibu...@gmail.com>:
>> >> >> >
>> >> >> > If we still can't reuse jakata artifacts (their license is ok and
>> >> there
>> >> >> is
>> >> >> > no impl reference inside so we should just use them, right?) it
>> >> sounds
>> >> >> > natural
>> >> >> >
>> >> >> > Romain Manni-Bucau
>> >> >> > @rmannibucau  |  Blog
>> >> >> >  | Old Blog
>> >> >> >  | Github <
>> >> >> https://github.com/rmannibucau> |
>> >> >> > LinkedIn  | Book
>> >> >> > <
>> >> >>
>> >>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> >> >> jlmonte...@tomitribe.com>
>> >> >> > a écrit :
>> >> >> >
>> >> >> >> Hi all,
>> >> >> >>
>> >> >> >> I was digging into some other specifications and see what would
>> pass
>> >> >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
>> >> >> actually
>> >> >> >> mixes 2 specifications.
>> >> >> >>
>> >> >> >> https://github.com/eclipse-ee4j/security-api
>> >> >> >>
>> >> >> >> and
>> >> >> >>
>> >> >> >> https://github.com/eclipse-ee4j/jaspic
>> >> >> >>
>> >> >> >> I thought the initial intent was to create a specific artifact
>> per
>> >> >> >> specification.
>> >> >> >> Mixing them is a bit annoying from a certification perspective.
>> >> >> >> It's also not clean because in Tomcat for instance, there is
>> already
>> >> >> >> jaspic API so it becomes a duplicate.
>> >> >> >>
>> >> >> >> Would it be possible to split them up in 2 artifacts?
>> >> >> >>
>> >> >> >> --
>> >> >> >> Jean-Louis Monteiro
>> >> >> >> http://twitter.com/jlouismonteiro
>> >> >> >> http://www.tomitribe.com
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >
>>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Jean-Louis Monteiro]

We can raise the issue at Jakarta

Meanwhile, can I remove the jaspic api classes because they really don't
have anything to do in this spec jar


--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Tue, Sep 3, 2019 at 4:37 PM Romain Manni-Bucau 
wrote:

> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity for
> us.
> That said it is good to reuse the same GAV for end users so we might ask
> jakarta to double license its api jars?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> a écrit :
>
> > Yep that was the point.
> > So I was asking if we should do the same yes or not.
> >
> > That seems to be your opinion Romain.
> > Mark on the other end is having some doubts about the license.
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau  >
> > wrote:
> >
> >> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com>
> >> a écrit :
> >>
> >> > Thanks Romain. I'm fine with using Eclipse jars if from a legal point
> of
> >> > view, it works.
> >> > Otherwise, I'd like to split our spec jars.
> >> >
> >> > What about MicroProfile?
> >> >
> >>
> >> We already agreed to not redo the API and use microprofile jars.
> >>
> >>
> >> > It's the same license and we are using them in our MicroProfile
> >> > implementations.
> >> > --
> >> > Jean-Louis Monteiro
> >> > http://twitter.com/jlouismonteiro
> >> > http://www.tomitribe.com
> >> >
> >> >
> >> > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg
>  >> >
> >> > wrote:
> >> >
> >> >> depends what their license is. EPL is (weak) copyleft. Thus I would
> >> like
> >> >> to avoid exposing it downstream as api.
> >> >>
> >> >> LieGrue,
> >> >> strub
> >> >>
> >> >>
> >> >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> >> >> rmannibu...@gmail.com>:
> >> >> >
> >> >> > If we still can't reuse jakata artifacts (their license is ok and
> >> there
> >> >> is
> >> >> > no impl reference inside so we should just use them, right?) it
> >> sounds
> >> >> > natural
> >> >> >
> >> >> > Romain Manni-Bucau
> >> >> > @rmannibucau  |  Blog
> >> >> >  | Old Blog
> >> >> >  | Github <
> >> >> https://github.com/rmannibucau> |
> >> >> > LinkedIn  | Book
> >> >> > <
> >> >>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >> >
> >> >> >
> >> >> >
> >> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> >> jlmonte...@tomitribe.com>
> >> >> > a écrit :
> >> >> >
> >> >> >> Hi all,
> >> >> >>
> >> >> >> I was digging into some other specifications and see what would
> pass
> >> >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
> >> >> actually
> >> >> >> mixes 2 specifications.
> >> >> >>
> >> >> >> https://github.com/eclipse-ee4j/security-api
> >> >> >>
> >> >> >> and
> >> >> >>
> >> >> >> https://github.com/eclipse-ee4j/jaspic
> >> >> >>
> >> >> >> I thought the initial intent was to create a specific artifact per
> >> >> >> specification.
> >> >> >> Mixing them is a bit annoying from a certification perspective.
> >> >> >> It's also not clean because in Tomcat for instance, there is
> already
> >> >> >> jaspic API so it becomes a duplicate.
> >> >> >>
> >> >> >> Would it be possible to split them up in 2 artifacts?
> >> >> >>
> >> >> >> --
> >> >> >> Jean-Louis Monteiro
> >> >> >> http://twitter.com/jlouismonteiro
> >> >> >> http://www.tomitribe.com
> >> >> >>
> >> >>
> >> >>
> >>
> >
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity for
us.
That said it is good to reuse the same GAV for end users so we might ask
jakarta to double license its api jars?

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



Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro 
a écrit :

> Yep that was the point.
> So I was asking if we should do the same yes or not.
>
> That seems to be your opinion Romain.
> Mark on the other end is having some doubts about the license.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau 
> wrote:
>
>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>> a écrit :
>>
>> > Thanks Romain. I'm fine with using Eclipse jars if from a legal point of
>> > view, it works.
>> > Otherwise, I'd like to split our spec jars.
>> >
>> > What about MicroProfile?
>> >
>>
>> We already agreed to not redo the API and use microprofile jars.
>>
>>
>> > It's the same license and we are using them in our MicroProfile
>> > implementations.
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> >
>> > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg > >
>> > wrote:
>> >
>> >> depends what their license is. EPL is (weak) copyleft. Thus I would
>> like
>> >> to avoid exposing it downstream as api.
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>
>> >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
>> >> rmannibu...@gmail.com>:
>> >> >
>> >> > If we still can't reuse jakata artifacts (their license is ok and
>> there
>> >> is
>> >> > no impl reference inside so we should just use them, right?) it
>> sounds
>> >> > natural
>> >> >
>> >> > Romain Manni-Bucau
>> >> > @rmannibucau  |  Blog
>> >> >  | Old Blog
>> >> >  | Github <
>> >> https://github.com/rmannibucau> |
>> >> > LinkedIn  | Book
>> >> > <
>> >>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >> >
>> >> >
>> >> >
>> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> >> jlmonte...@tomitribe.com>
>> >> > a écrit :
>> >> >
>> >> >> Hi all,
>> >> >>
>> >> >> I was digging into some other specifications and see what would pass
>> >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
>> >> actually
>> >> >> mixes 2 specifications.
>> >> >>
>> >> >> https://github.com/eclipse-ee4j/security-api
>> >> >>
>> >> >> and
>> >> >>
>> >> >> https://github.com/eclipse-ee4j/jaspic
>> >> >>
>> >> >> I thought the initial intent was to create a specific artifact per
>> >> >> specification.
>> >> >> Mixing them is a bit annoying from a certification perspective.
>> >> >> It's also not clean because in Tomcat for instance, there is already
>> >> >> jaspic API so it becomes a duplicate.
>> >> >>
>> >> >> Would it be possible to split them up in 2 artifacts?
>> >> >>
>> >> >> --
>> >> >> Jean-Louis Monteiro
>> >> >> http://twitter.com/jlouismonteiro
>> >> >> http://www.tomitribe.com
>> >> >>
>> >>
>> >>
>>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Jean-Louis Monteiro]

Yep that was the point.
So I was asking if we should do the same yes or not.

That seems to be your opinion Romain.
Mark on the other end is having some doubts about the license.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau 
wrote:

> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> a écrit :
>
> > Thanks Romain. I'm fine with using Eclipse jars if from a legal point of
> > view, it works.
> > Otherwise, I'd like to split our spec jars.
> >
> > What about MicroProfile?
> >
>
> We already agreed to not redo the API and use microprofile jars.
>
>
> > It's the same license and we are using them in our MicroProfile
> > implementations.
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg 
> > wrote:
> >
> >> depends what their license is. EPL is (weak) copyleft. Thus I would like
> >> to avoid exposing it downstream as api.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com>:
> >> >
> >> > If we still can't reuse jakata artifacts (their license is ok and
> there
> >> is
> >> > no impl reference inside so we should just use them, right?) it sounds
> >> > natural
> >> >
> >> > Romain Manni-Bucau
> >> > @rmannibucau  |  Blog
> >> >  | Old Blog
> >> >  | Github <
> >> https://github.com/rmannibucau> |
> >> > LinkedIn  | Book
> >> > <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >> >
> >> >
> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com>
> >> > a écrit :
> >> >
> >> >> Hi all,
> >> >>
> >> >> I was digging into some other specifications and see what would pass
> >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
> >> actually
> >> >> mixes 2 specifications.
> >> >>
> >> >> https://github.com/eclipse-ee4j/security-api
> >> >>
> >> >> and
> >> >>
> >> >> https://github.com/eclipse-ee4j/jaspic
> >> >>
> >> >> I thought the initial intent was to create a specific artifact per
> >> >> specification.
> >> >> Mixing them is a bit annoying from a certification perspective.
> >> >> It's also not clean because in Tomcat for instance, there is already
> >> >> jaspic API so it becomes a duplicate.
> >> >>
> >> >> Would it be possible to split them up in 2 artifacts?
> >> >>
> >> >> --
> >> >> Jean-Louis Monteiro
> >> >> http://twitter.com/jlouismonteiro
> >> >> http://www.tomitribe.com
> >> >>
> >>
> >>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro 
a écrit :

> Thanks Romain. I'm fine with using Eclipse jars if from a legal point of
> view, it works.
> Otherwise, I'd like to split our spec jars.
>
> What about MicroProfile?
>

We already agreed to not redo the API and use microprofile jars.


> It's the same license and we are using them in our MicroProfile
> implementations.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg 
> wrote:
>
>> depends what their license is. EPL is (weak) copyleft. Thus I would like
>> to avoid exposing it downstream as api.
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
>> >
>> > If we still can't reuse jakata artifacts (their license is ok and there
>> is
>> > no impl reference inside so we should just use them, right?) it sounds
>> > natural
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau  |  Blog
>> >  | Old Blog
>> >  | Github <
>> https://github.com/rmannibucau> |
>> > LinkedIn  | Book
>> > <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>> >
>> >
>> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>> > a écrit :
>> >
>> >> Hi all,
>> >>
>> >> I was digging into some other specifications and see what would pass
>> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
>> actually
>> >> mixes 2 specifications.
>> >>
>> >> https://github.com/eclipse-ee4j/security-api
>> >>
>> >> and
>> >>
>> >> https://github.com/eclipse-ee4j/jaspic
>> >>
>> >> I thought the initial intent was to create a specific artifact per
>> >> specification.
>> >> Mixing them is a bit annoying from a certification perspective.
>> >> It's also not clean because in Tomcat for instance, there is already
>> >> jaspic API so it becomes a duplicate.
>> >>
>> >> Would it be possible to split them up in 2 artifacts?
>> >>
>> >> --
>> >> Jean-Louis Monteiro
>> >> http://twitter.com/jlouismonteiro
>> >> http://www.tomitribe.com
>> >>
>>
>>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Jean-Louis Monteiro]

Thanks Romain. I'm fine with using Eclipse jars if from a legal point of
view, it works.
Otherwise, I'd like to split our spec jars.

What about MicroProfile?
It's the same license and we are using them in our MicroProfile
implementations.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg 
wrote:

> depends what their license is. EPL is (weak) copyleft. Thus I would like
> to avoid exposing it downstream as api.
>
> LieGrue,
> strub
>
>
> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau  >:
> >
> > If we still can't reuse jakata artifacts (their license is ok and there
> is
> > no impl reference inside so we should just use them, right?) it sounds
> > natural
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> > a écrit :
> >
> >> Hi all,
> >>
> >> I was digging into some other specifications and see what would pass
> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
> actually
> >> mixes 2 specifications.
> >>
> >> https://github.com/eclipse-ee4j/security-api
> >>
> >> and
> >>
> >> https://github.com/eclipse-ee4j/jaspic
> >>
> >> I thought the initial intent was to create a specific artifact per
> >> specification.
> >> Mixing them is a bit annoying from a certification perspective.
> >> It's also not clean because in Tomcat for instance, there is already
> >> jaspic API so it becomes a duplicate.
> >>
> >> Would it be possible to split them up in 2 artifacts?
> >>
> >> --
> >> Jean-Louis Monteiro
> >> http://twitter.com/jlouismonteiro
> >> http://www.tomitribe.com
> >>
>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Mark Struberg]

depends what their license is. EPL is (weak) copyleft. Thus I would like to 
avoid exposing it downstream as api.

LieGrue,
strub


> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau :
> 
> If we still can't reuse jakata artifacts (their license is ok and there is
> no impl reference inside so we should just use them, right?) it sounds
> natural
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro 
> a écrit :
> 
>> Hi all,
>> 
>> I was digging into some other specifications and see what would pass
>> Jakarta TCK and realized that geronimo-security_1.0_spec content actually
>> mixes 2 specifications.
>> 
>> https://github.com/eclipse-ee4j/security-api
>> 
>> and
>> 
>> https://github.com/eclipse-ee4j/jaspic
>> 
>> I thought the initial intent was to create a specific artifact per
>> specification.
>> Mixing them is a bit annoying from a certification perspective.
>> It's also not clean because in Tomcat for instance, there is already
>> jaspic API so it becomes a duplicate.
>> 
>> Would it be possible to split them up in 2 artifacts?
>> 
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>> 

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

If we still can't reuse jakata artifacts (their license is ok and there is
no impl reference inside so we should just use them, right?) it sounds
natural

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



Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro 
a écrit :

> Hi all,
>
> I was digging into some other specifications and see what would pass
> Jakarta TCK and realized that geronimo-security_1.0_spec content actually
> mixes 2 specifications.
>
> https://github.com/eclipse-ee4j/security-api
>
> and
>
> https://github.com/eclipse-ee4j/jaspic
>
> I thought the initial intent was to create a specific artifact per
> specification.
> Mixing them is a bit annoying from a certification perspective.
> It's also not clean because in Tomcat for instance, there is already
> jaspic API so it becomes a duplicate.
>
> Would it be possible to split them up in 2 artifacts?
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

DISCUSS geronimo-security_1.0_spec content unclear

[Jean-Louis Monteiro]

Hi all,

I was digging into some other specifications and see what would pass
Jakarta TCK and realized that geronimo-security_1.0_spec content actually
mixes 2 specifications.

https://github.com/eclipse-ee4j/security-api

and

https://github.com/eclipse-ee4j/jaspic

I thought the initial intent was to create a specific artifact per
specification.
Mixing them is a bit annoying from a certification perspective.
It's also not clean because in Tomcat for instance, there is already jaspic
API so it becomes a duplicate.

Would it be possible to split them up in 2 artifacts?

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

Re: DISCUSS Release for Geronimo Annotations 1.3

[Mark Struberg]

+1

LieGrue,
strub


> Am 03.09.2019 um 09:45 schrieb Romain Manni-Bucau :
> 
> +1
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mar. 3 sept. 2019 à 09:44, Jean-Louis MONTEIRO  a 
> écrit :
> Everything is green now
> 
> 
> am I ok to run the release?
> 
> 
> Le mar. 3 sept. 2019 à 09:35, Romain Manni-Bucau  a 
> écrit :
> Oki so let's get it out :)
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mar. 3 sept. 2019 à 09:18, Jean-Louis MONTEIRO  a 
> écrit :
> Hi Romain,
> 
> This is the changes I made.
> Nothing big or potentially breaking applications.
> 
> It's the signature part yes.
> Basically @Repeatable was missing on @Resource and @DataSourceDefinition
> 
> See https://svn.apache.org/viewvc?view=revision&revision=1866293
> 
> 
> 
> 
> 
> Le lun. 2 sept. 2019 à 23:29, Romain Manni-Bucau  a 
> écrit :
> Hi JL,
> 
> I didnt find the commits in mail archives, is it a list setup issue? Does it 
> break binary compatibility/class or method signatures?
> 
> Otherwise it sounds good. Can test on a few projects relying on annotation 
> bundle tomorrow.
> 
> Le lun. 2 sept. 2019 à 23:06, Jean-Louis MONTEIRO  a 
> écrit :
> Hi guys,
> 
> I ran the TCK for Annotations 1.3.
> It's simple as it's only signature validation.
> 
> I found 2 issues that I fixed and now I'd like to do the actual release.
> Is that ok?
> 
> -- 
> Jean-Louis
> 
> 
> -- 
> Jean-Louis
> 
> 
> -- 
> Jean-Louis

Re: [VOTE] Release geronimo-annotation-1.3 spec API

[Romain Manni-Bucau]

+1

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



Le mar. 3 sept. 2019 à 15:29, Jean-Baptiste Onofré  a
écrit :

> +1 (non binding)
>
> Regards
> JB
>
> On 03/09/2019 10:04, Jean-Louis MONTEIRO wrote:
> > Hi!
> >
> > I’d like to call a VOTE on the geronimo-annotation-1.3_spec-1.2 jar.
> > This is an API which implements the common-annotations JSR-250
> > 1.3 specification.
> >
> > The only change was the introduction of @Repeatable on both @Resource
> > and @DataSourceDefinition so that we can now pass the Jakarta TCK.
> >
> > Here is the staging repo
> >
> https://repository.apache.org/content/repositories/orgapachegeronimo-1109/
> >
> > And the source jar which is voted on
> >
> https://repository.apache.org/content/repositories/orgapachegeronimo-1109/org/apache/geronimo/specs/geronimo-annotation_1.3_spec/1.2/geronimo-annotation_1.3_spec-1.2-source-release.zip
> >
> >
> > My key can be found at
> > https://svn.apache.org/repos/asf/geronimo/KEYS
> >
> > please VOTE
> > [+1] all fine, ship it
> > [+0] don't care
> > [-1] stop, because ${reason}
> >
> > The VOTE is open for 72h.
> >
> > --
> > Jean-Louis
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [VOTE] Release geronimo-annotation-1.3 spec API

[Jean-Baptiste Onofré]

+1 (non binding)

Regards
JB

On 03/09/2019 10:04, Jean-Louis MONTEIRO wrote:
> Hi!
> 
> I’d like to call a VOTE on the geronimo-annotation-1.3_spec-1.2 jar.
> This is an API which implements the common-annotations JSR-250
> 1.3 specification.
> 
> The only change was the introduction of @Repeatable on both @Resource
> and @DataSourceDefinition so that we can now pass the Jakarta TCK.
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1109/
> 
> And the source jar which is voted on
> https://repository.apache.org/content/repositories/orgapachegeronimo-1109/org/apache/geronimo/specs/geronimo-annotation_1.3_spec/1.2/geronimo-annotation_1.3_spec-1.2-source-release.zip
> 
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> 
> -- 
> Jean-Louis

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release geronimo-annotation-1.3 spec API

[Raymond Auge]

+1

- Ray

On Tue, Sep 3, 2019 at 4:05 AM Jean-Louis MONTEIRO 
wrote:

> Hi!
>
> I’d like to call a VOTE on the geronimo-annotation-1.3_spec-1.2 jar.
> This is an API which implements the common-annotations JSR-250 1.3
> specification.
>
> The only change was the introduction of @Repeatable on both @Resource
> and @DataSourceDefinition so that we can now pass the Jakarta TCK.
>
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1109/
>
> And the source jar which is voted on
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-1109/org/apache/geronimo/specs/geronimo-annotation_1.3_spec/1.2/geronimo-annotation_1.3_spec-1.2-source-release.zip
>
>
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
>
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
>
> The VOTE is open for 72h.
>
> --
> Jean-Louis
>


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

[GitHub] [geronimo-openapi] edenhaus commented on issue #17: Always use reusable object component

[GitBox]

edenhaus commented on issue #17: Always use reusable object component
URL: https://github.com/apache/geronimo-openapi/pull/17#issuecomment-527367747
 
 
   Perfect :)
   I will close than this pullrequest


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


With regards,
Apache Git Services

[GitHub] [geronimo-openapi] edenhaus closed pull request #17: Always use reusable object component

[GitBox]

edenhaus closed pull request #17: Always use reusable object component
URL: https://github.com/apache/geronimo-openapi/pull/17
 
 
   


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


With regards,
Apache Git Services

[VOTE] Release geronimo-annotation-1.3 spec API

[Jean-Louis MONTEIRO]

Hi!

I’d like to call a VOTE on the geronimo-annotation-1.3_spec-1.2 jar.
This is an API which implements the common-annotations JSR-250 1.3
specification.

The only change was the introduction of @Repeatable on both @Resource
and @DataSourceDefinition so that we can now pass the Jakarta TCK.

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

And the source jar which is voted on
https://repository.apache.org/content/repositories/orgapachegeronimo-1109/org/apache/geronimo/specs/geronimo-annotation_1.3_spec/1.2/geronimo-annotation_1.3_spec-1.2-source-release.zip


My key can be found at
https://svn.apache.org/repos/asf/geronimo/KEYS

please VOTE
[+1] all fine, ship it
[+0] don't care
[-1] stop, because ${reason}

The VOTE is open for 72h.

-- 
Jean-Louis

Re: DISCUSS Release for Geronimo Annotations 1.3

[Romain Manni-Bucau]

+1

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



Le mar. 3 sept. 2019 à 09:44, Jean-Louis MONTEIRO  a
écrit :

> Everything is green now
> [image: image.png]
>
> am I ok to run the release?
>
>
> Le mar. 3 sept. 2019 à 09:35, Romain Manni-Bucau 
> a écrit :
>
>> Oki so let's get it out :)
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>>
>> Le mar. 3 sept. 2019 à 09:18, Jean-Louis MONTEIRO  a
>> écrit :
>>
>>> Hi Romain,
>>>
>>> This is the changes I made.
>>> Nothing big or potentially breaking applications.
>>>
>>> It's the signature part yes.
>>> Basically @Repeatable was missing on @Resource and @DataSourceDefinition
>>>
>>> See https://svn.apache.org/viewvc?view=revision&revision=1866293
>>>
>>>
>>>
>>>
>>>
>>> Le lun. 2 sept. 2019 à 23:29, Romain Manni-Bucau 
>>> a écrit :
>>>
 Hi JL,

 I didnt find the commits in mail archives, is it a list setup issue?
 Does it break binary compatibility/class or method signatures?

 Otherwise it sounds good. Can test on a few projects relying on
 annotation bundle tomorrow.

 Le lun. 2 sept. 2019 à 23:06, Jean-Louis MONTEIRO 
 a écrit :

> Hi guys,
>
> I ran the TCK for Annotations 1.3.
> It's simple as it's only signature validation.
>
> I found 2 issues that I fixed and now I'd like to do the actual
> release.
> Is that ok?
>
> --
> Jean-Louis
>

>>>
>>> --
>>> Jean-Louis
>>>
>>
>
> --
> Jean-Louis
>

Re: DISCUSS Release for Geronimo Annotations 1.3

[Jean-Louis MONTEIRO]

Everything is green now
[image: image.png]

am I ok to run the release?


Le mar. 3 sept. 2019 à 09:35, Romain Manni-Bucau  a
écrit :

> Oki so let's get it out :)
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le mar. 3 sept. 2019 à 09:18, Jean-Louis MONTEIRO  a
> écrit :
>
>> Hi Romain,
>>
>> This is the changes I made.
>> Nothing big or potentially breaking applications.
>>
>> It's the signature part yes.
>> Basically @Repeatable was missing on @Resource and @DataSourceDefinition
>>
>> See https://svn.apache.org/viewvc?view=revision&revision=1866293
>>
>>
>>
>>
>>
>> Le lun. 2 sept. 2019 à 23:29, Romain Manni-Bucau 
>> a écrit :
>>
>>> Hi JL,
>>>
>>> I didnt find the commits in mail archives, is it a list setup issue?
>>> Does it break binary compatibility/class or method signatures?
>>>
>>> Otherwise it sounds good. Can test on a few projects relying on
>>> annotation bundle tomorrow.
>>>
>>> Le lun. 2 sept. 2019 à 23:06, Jean-Louis MONTEIRO 
>>> a écrit :
>>>
 Hi guys,

 I ran the TCK for Annotations 1.3.
 It's simple as it's only signature validation.

 I found 2 issues that I fixed and now I'd like to do the actual release.
 Is that ok?

 --
 Jean-Louis

>>>
>>
>> --
>> Jean-Louis
>>
>

-- 
Jean-Louis

Re: DISCUSS Release for Geronimo Annotations 1.3

[Romain Manni-Bucau]

Oki so let's get it out :)

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



Le mar. 3 sept. 2019 à 09:18, Jean-Louis MONTEIRO  a
écrit :

> Hi Romain,
>
> This is the changes I made.
> Nothing big or potentially breaking applications.
>
> It's the signature part yes.
> Basically @Repeatable was missing on @Resource and @DataSourceDefinition
>
> See https://svn.apache.org/viewvc?view=revision&revision=1866293
>
>
>
>
>
> Le lun. 2 sept. 2019 à 23:29, Romain Manni-Bucau 
> a écrit :
>
>> Hi JL,
>>
>> I didnt find the commits in mail archives, is it a list setup issue? Does
>> it break binary compatibility/class or method signatures?
>>
>> Otherwise it sounds good. Can test on a few projects relying on
>> annotation bundle tomorrow.
>>
>> Le lun. 2 sept. 2019 à 23:06, Jean-Louis MONTEIRO  a
>> écrit :
>>
>>> Hi guys,
>>>
>>> I ran the TCK for Annotations 1.3.
>>> It's simple as it's only signature validation.
>>>
>>> I found 2 issues that I fixed and now I'd like to do the actual release.
>>> Is that ok?
>>>
>>> --
>>> Jean-Louis
>>>
>>
>
> --
> Jean-Louis
>

[GitHub] [geronimo-openapi] rmannibucau commented on issue #17: Always use reusable object component

[GitBox]

rmannibucau commented on issue #17: Always use reusable object component
URL: https://github.com/apache/geronimo-openapi/pull/17#issuecomment-527341543
 
 
   Hi @edenhaus,
   
   merged and referenced in GERONIMO-6749
   
   Thanks a lot for your help and PR!


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


With regards,
Apache Git Services

[jira] [Resolved] (GERONIMO-6749) Ensure to always use schema reference and never put it inline to ensure determinism of the openapi.json

[Romain Manni-Bucau (Jira)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Manni-Bucau resolved GERONIMO-6749.
--
Resolution: Fixed

> Ensure to always use schema reference and never put it inline to ensure 
> determinism of the openapi.json
> ---
>
> Key: GERONIMO-6749
> URL: https://issues.apache.org/jira/browse/GERONIMO-6749
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: OpenAPI_1.0.11
>Reporter: Romain Manni-Bucau
>Priority: Major
> Fix For: OpenAPI_1.0.12
>
>




--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (GERONIMO-6749) Ensure to always use schema reference and never put it inline to ensure determinism of the openapi.json

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created GERONIMO-6749:


 Summary: Ensure to always use schema reference and never put it 
inline to ensure determinism of the openapi.json
 Key: GERONIMO-6749
 URL: https://issues.apache.org/jira/browse/GERONIMO-6749
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
Affects Versions: OpenAPI_1.0.11
Reporter: Romain Manni-Bucau
 Fix For: OpenAPI_1.0.12






--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: DISCUSS Release for Geronimo Annotations 1.3

[Jean-Louis MONTEIRO]

Hi Romain,

This is the changes I made.
Nothing big or potentially breaking applications.

It's the signature part yes.
Basically @Repeatable was missing on @Resource and @DataSourceDefinition

See https://svn.apache.org/viewvc?view=revision&revision=1866293





Le lun. 2 sept. 2019 à 23:29, Romain Manni-Bucau  a
écrit :

> Hi JL,
>
> I didnt find the commits in mail archives, is it a list setup issue? Does
> it break binary compatibility/class or method signatures?
>
> Otherwise it sounds good. Can test on a few projects relying on annotation
> bundle tomorrow.
>
> Le lun. 2 sept. 2019 à 23:06, Jean-Louis MONTEIRO  a
> écrit :
>
>> Hi guys,
>>
>> I ran the TCK for Annotations 1.3.
>> It's simple as it's only signature validation.
>>
>> I found 2 issues that I fixed and now I'd like to do the actual release.
>> Is that ok?
>>
>> --
>> Jean-Louis
>>
>

-- 
Jean-Louis