Re: DISCUSS geronimo-security_1.0_spec content unclear

[Mark Struberg]

Yes, that's a sane approach.
EPL just requires us to have it mentioned in every downstream NOTICE iiuc.

From the EPL v2 [1]

3.1 If a Contributor Distributes the Program in any form, then:
• a) the Program must also be made available as Source Code, in 
accordance with section 3.2, and the Contributor must accompany the Program 
with a statement that the Source Code for the Program is available under this 
Agreement, and informs Recipients how to obtain it in a reasonable manner on or 
through a medium customarily used for software exchange; and...


For TomEE we'd need to add it to our NOTICE for example, right [2]?

This is likely not a problem for TomEE, but might be something to know if some 
project has a fat-jar approach. In this case this weak-copyleft semantic also 
spreads over to the customer project. Not a show-stopper, but something to 
consider.

LieGrue,
strub

[1] https://www.eclipse.org/legal/epl-2.0/
[2] https://github.com/apache/tomee/blob/master/NOTICE


> Am 04.09.2019 um 23:51 schrieb David Blevins :
> 
>> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau  wrote:
>> 
>> No I guess it was right, "that are" ;) = fork @G only when we need to
>> change some impl/default provider.
> 
> Right.  A few things in my mind at least:
> 
> - Industry health: we (Apache) are the only other implementations of 
> Activation, JavaMail, JACC and similar "impl" specs.  If we give up on the 
> impls we have, the industry collapses down to one impl and then what is the 
> point of a spec?
> 
> - Competitiveness: we have seen performance issues reported against our 
> impls.  I distinctly remember one for JACC several years ago.  Where there 
> are issues, there are also potential advantages.  If we can handle it, let's 
> keep our impls and be competitive.
> 
> Where there is no actual impl I don't see any gain for the effort even if 
> small.
> 
> - Unavoidable EPL dependence: We're not likely to write a new Java compiler 
> any time soon, so we're stuck with the EPL forever.
> 
> - Likelyhood of increased EPL dependence: Given it is the default choice in 
> Jakarta, more things will be created under it we may need.
> 
> - Decreasing helping hands: Projects at Apache are switching over to the EPL 
> libraries, so we will have fewer people willing to type in APIs for 
> already-thin legal reasons.
> 
> 
> -David
> 

Re: DISCUSS geronimo-security_1.0_spec content unclear

[David Blevins]

> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau  wrote:
> 
> No I guess it was right, "that are" ;) = fork @G only when we need to
> change some impl/default provider.

Right.  A few things in my mind at least:

 - Industry health: we (Apache) are the only other implementations of 
Activation, JavaMail, JACC and similar "impl" specs.  If we give up on the 
impls we have, the industry collapses down to one impl and then what is the 
point of a spec?

 - Competitiveness: we have seen performance issues reported against our impls. 
 I distinctly remember one for JACC several years ago.  Where there are issues, 
there are also potential advantages.  If we can handle it, let's keep our impls 
and be competitive.

Where there is no actual impl I don't see any gain for the effort even if small.

 - Unavoidable EPL dependence: We're not likely to write a new Java compiler 
any time soon, so we're stuck with the EPL forever.

 - Likelyhood of increased EPL dependence: Given it is the default choice in 
Jakarta, more things will be created under it we may need.

 - Decreasing helping hands: Projects at Apache are switching over to the EPL 
libraries, so we will have fewer people willing to type in APIs for 
already-thin legal reasons.


-David

Re: DISCUSS geronimo-security_1.0_spec content unclear

[David Blevins]

> On Sep 4, 2019, at 6:04 AM, Mark Struberg  wrote:
> 
> No, this is an intended situation.
> When one fully passes the TCK then you get the EFSL. This 'removes' the 
> copyleft nature of the EPL.
> The details are quite nested in the legal papers, but that's it basically.
> 
> If we just upgrade our existing API to be binary compat then we have no IP 
> issues.

I'm not sure I understand what's being said with the above.

If it is helpful I can add to the conversation:

 - The EFSL only applies to specification PDF, HTML and Javadoc.  It does not 
apply to the API jars.
 - The EFSL is not an OSI-approved license and not Approved by the Apache Board 
as safe to ship.



-David

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

We cant, only impl+api are certified so no issue ;)

Le mer. 4 sept. 2019 à 17:01, Jean-Louis Monteiro 
a écrit :

> I'd like to certify some of them if possible of course.
>
> Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau 
> a écrit :
>
>> Not sure I'm following Mark, EPL is fine for us (
>> https://www.apache.org/legal/resolved.html) and G spec jars are not
>> officially certified so don't change of license anytime.
>>
>> 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 mer. 4 sept. 2019 à 15:07, Mark Struberg  a écrit :
>>
>> > No, before that it was CDDL+GPL. It just moved to EPL, which is also
>> CatB
>> >
>> > LieGrue,
>> > strub
>> >
>> > > Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
>> > >:
>> > >
>> > > @Mark: didn't change with jakarta donation? can you open a ticket on
>> > > jakartee tracker please?
>> > >
>> > > 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 mer. 4 sept. 2019 à 15:04, Mark Struberg  a
>> écrit
>> > :
>> > >
>> > >> No, this is an intended situation.
>> > >> When one fully passes the TCK then you get the EFSL. This 'removes'
>> the
>> > >> copyleft nature of the EPL.
>> > >> The details are quite nested in the legal papers, but that's it
>> > basically.
>> > >>
>> > >> If we just upgrade our existing API to be binary compat then we have
>> no
>> > IP
>> > >> issues.
>> > >>
>> > >> LieGrue,
>> > >> strub
>> > >>
>> > >>
>> > >>> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau <
>> > rmannibu...@gmail.com
>> > >>> :
>> > >>>
>> > >>> 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 <
>> > >> 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 à 

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

Not sure I'm following Mark, EPL is fine for us (
https://www.apache.org/legal/resolved.html) and G spec jars are not
officially certified so don't change of license anytime.

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



Le mer. 4 sept. 2019 à 15:07, Mark Struberg  a écrit :

> No, before that it was CDDL+GPL. It just moved to EPL, which is also CatB
>
> LieGrue,
> strub
>
> > Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau  >:
> >
> > @Mark: didn't change with jakarta donation? can you open a ticket on
> > jakartee tracker please?
> >
> > 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 mer. 4 sept. 2019 à 15:04, Mark Struberg  a écrit
> :
> >
> >> No, this is an intended situation.
> >> When one fully passes the TCK then you get the EFSL. This 'removes' the
> >> copyleft nature of the EPL.
> >> The details are quite nested in the legal papers, but that's it
> basically.
> >>
> >> If we just upgrade our existing API to be binary compat then we have no
> IP
> >> issues.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> 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 <
> >> 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 

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Mark Struberg]

No, before that it was CDDL+GPL. It just moved to EPL, which is also CatB

LieGrue,
strub

> Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau :
> 
> @Mark: didn't change with jakarta donation? can you open a ticket on
> jakartee tracker please?
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mer. 4 sept. 2019 à 15:04, Mark Struberg  a écrit :
> 
>> No, this is an intended situation.
>> When one fully passes the TCK then you get the EFSL. This 'removes' the
>> copyleft nature of the EPL.
>> The details are quite nested in the legal papers, but that's it basically.
>> 
>> If we just upgrade our existing API to be binary compat then we have no IP
>> issues.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 03.09.2019 um 16:37 schrieb 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 <
>> 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]

@Mark: didn't change with jakarta donation? can you open a ticket on
jakartee tracker please?

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



Le mer. 4 sept. 2019 à 15:04, Mark Struberg  a écrit :

> No, this is an intended situation.
> When one fully passes the TCK then you get the EFSL. This 'removes' the
> copyleft nature of the EPL.
> The details are quite nested in the legal papers, but that's it basically.
>
> If we just upgrade our existing API to be binary compat then we have no IP
> issues.
>
> LieGrue,
> strub
>
>
> > Am 03.09.2019 um 16:37 schrieb 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 <
> 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

[Mark Struberg]

No, this is an intended situation.
When one fully passes the TCK then you get the EFSL. This 'removes' the 
copyleft nature of the EPL.
The details are quite nested in the legal papers, but that's it basically.

If we just upgrade our existing API to be binary compat then we have no IP 
issues.

LieGrue,
strub


> Am 03.09.2019 um 16:37 schrieb 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 
> 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]

exactly.
Main ambiguity is for API using a provider as only impl dependency like
jsonp/jsonb (
https://github.com/apache/geronimo-specs/blob/trunk/geronimo-jsonb_1.0_spec/src/main/java/javax/json/bind/spi/JsonbProvider.java#L30
).
Think it makes sense to keep it hosted to change this value even if system
props/SPI enable to switch it since it enables to make fatjars smooths
without configs and to ensure we load the right default but it is really a
single string so can be discussed.

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



Le mer. 4 sept. 2019 à 11:16, Jean-Louis Monteiro 
a écrit :

> so for instance activation and javamail would stay in Geronimo Specs and
> let's say @Inject would be Eclipse?
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Wed, Sep 4, 2019 at 11:11 AM Romain Manni-Bucau 
> wrote:
>
>> No I guess it was right, "that are" ;) = fork @G only when we need to
>> change some impl/default provider.
>>
>>
>> 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 mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>> a écrit :
>>
>> > > This is my current thinking as well; maintain apis that are impls, use
>> > the EPL version otherwise.
>> > I believe you meant "that are not impls ..."
>> >
>> > I'll make the changes on the javaee-api jar
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> >
>> > On Tue, Sep 3, 2019 at 8:07 PM David Blevins 
>> > wrote:
>> >
>> >> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> >> 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 <
>> >> 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]

so for instance activation and javamail would stay in Geronimo Specs and
let's say @Inject would be Eclipse?
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Wed, Sep 4, 2019 at 11:11 AM Romain Manni-Bucau 
wrote:

> No I guess it was right, "that are" ;) = fork @G only when we need to
> change some impl/default provider.
>
>
> 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 mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> a écrit :
>
> > > This is my current thinking as well; maintain apis that are impls, use
> > the EPL version otherwise.
> > I believe you meant "that are not impls ..."
> >
> > I'll make the changes on the javaee-api jar
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Sep 3, 2019 at 8:07 PM David Blevins 
> > wrote:
> >
> >> > 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 <
> >> 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]

No I guess it was right, "that are" ;) = fork @G only when we need to
change some impl/default provider.


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



Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro 
a écrit :

> > This is my current thinking as well; maintain apis that are impls, use
> the EPL version otherwise.
> I believe you meant "that are not impls ..."
>
> I'll make the changes on the javaee-api jar
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Sep 3, 2019 at 8:07 PM David Blevins 
> wrote:
>
>> > 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 <
>> 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]

> This is my current thinking as well; maintain apis that are impls, use
the EPL version otherwise.
I believe you meant "that are not impls ..."

I'll make the changes on the javaee-api jar

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


On Tue, Sep 3, 2019 at 8:07 PM David Blevins 
wrote:

> > 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 <
> 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

[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: 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