You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jean-Louis Monteiro <jl...@tomitribe.com> on 2019/09/03 14:18:35 UTC
DISCUSS geronimo-security_1.0_spec content unclear
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
Posted by David Blevins <da...@gmail.com>.
> On Sep 4, 2019, at 6:04 AM, Mark Struberg <st...@yahoo.de> 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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
We cant, only impl+api are certified so no issue ;)
Le mer. 4 sept. 2019 à 17:01, Jean-Louis Monteiro <jl...@tomitribe.com>
a écrit :
> I'd like to certify some of them if possible of course.
>
> Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau <rm...@gmail.com>
> 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 <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mer. 4 sept. 2019 à 15:07, Mark Struberg <st...@yahoo.de> 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 <
>> rmannibucau@gmail.com
>> > >:
>> > >
>> > > @Mark: didn't change with jakarta donation? can you open a ticket on
>> > > jakartee tracker please?
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > > <https://rmannibucau.metawerx.net/> | Old Blog
>> > > <http://rmannibucau.wordpress.com> | Github <
>> > https://github.com/rmannibucau> |
>> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > > <
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > >
>> > >
>> > >
>> > > Le mer. 4 sept. 2019 à 15:04, Mark Struberg <st...@yahoo.de> 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 <
>> > rmannibucau@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 <
>> > >> jlmonteiro@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 <
>> > rmannibucau@gmail.com>
>> > >> wrote:
>> > >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> > >> jlmonteiro@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
>> > <struberg@yahoo.de.invalid
>> > >>>
>> > >>>> 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 <
>> > >>>>> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
>> > >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>> > >>>>>> <http://rmannibucau.wordpress.com> | Github <
>> > >>>>> https://github.com/rmannibucau> |
>> > >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > >>>>>> <
>> > >>>>>
>> > >>
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> > >>>>> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
We cant, only impl+api are certified so no issue ;)
Le mer. 4 sept. 2019 à 17:01, Jean-Louis Monteiro <jl...@tomitribe.com>
a écrit :
> I'd like to certify some of them if possible of course.
>
> Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau <rm...@gmail.com>
> 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 <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mer. 4 sept. 2019 à 15:07, Mark Struberg <st...@yahoo.de> 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 <
>> rmannibucau@gmail.com
>> > >:
>> > >
>> > > @Mark: didn't change with jakarta donation? can you open a ticket on
>> > > jakartee tracker please?
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > > <https://rmannibucau.metawerx.net/> | Old Blog
>> > > <http://rmannibucau.wordpress.com> | Github <
>> > https://github.com/rmannibucau> |
>> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > > <
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > >
>> > >
>> > >
>> > > Le mer. 4 sept. 2019 à 15:04, Mark Struberg <st...@yahoo.de> 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 <
>> > rmannibucau@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 <
>> > >> jlmonteiro@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 <
>> > rmannibucau@gmail.com>
>> > >> wrote:
>> > >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> > >> jlmonteiro@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
>> > <struberg@yahoo.de.invalid
>> > >>>
>> > >>>> 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 <
>> > >>>>> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
>> > >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>> > >>>>>> <http://rmannibucau.wordpress.com> | Github <
>> > >>>>> https://github.com/rmannibucau> |
>> > >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > >>>>>> <
>> > >>>>>
>> > >>
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> > >>>>> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
I'd like to certify some of them if possible of course.
Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau <rm...@gmail.com> 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 <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 4 sept. 2019 à 15:07, Mark Struberg <st...@yahoo.de> 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 <
> rmannibucau@gmail.com
> > >:
> > >
> > > @Mark: didn't change with jakarta donation? can you open a ticket on
> > > jakartee tracker please?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mer. 4 sept. 2019 à 15:04, Mark Struberg <st...@yahoo.de> 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 <
> > rmannibucau@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 <
> > >> jlmonteiro@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 <
> > rmannibucau@gmail.com>
> > >> wrote:
> > >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> > >> jlmonteiro@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
> > <struberg@yahoo.de.invalid
> > >>>
> > >>>> 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 <
> > >>>>> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> > >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > >>>>>> <http://rmannibucau.wordpress.com> | Github <
> > >>>>> https://github.com/rmannibucau> |
> > >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >>>>>> <
> > >>>>>
> > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> > >>>>> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
I'd like to certify some of them if possible of course.
Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau <rm...@gmail.com> 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 <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 4 sept. 2019 à 15:07, Mark Struberg <st...@yahoo.de> 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 <
> rmannibucau@gmail.com
> > >:
> > >
> > > @Mark: didn't change with jakarta donation? can you open a ticket on
> > > jakartee tracker please?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mer. 4 sept. 2019 à 15:04, Mark Struberg <st...@yahoo.de> 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 <
> > rmannibucau@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 <
> > >> jlmonteiro@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 <
> > rmannibucau@gmail.com>
> > >> wrote:
> > >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> > >> jlmonteiro@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
> > <struberg@yahoo.de.invalid
> > >>>
> > >>>> 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 <
> > >>>>> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> > >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > >>>>>> <http://rmannibucau.wordpress.com> | Github <
> > >>>>> https://github.com/rmannibucau> |
> > >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >>>>>> <
> > >>>>>
> > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> > >>>>> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 4 sept. 2019 à 15:07, Mark Struberg <st...@yahoo.de> 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 <rmannibucau@gmail.com
> >:
> >
> > @Mark: didn't change with jakarta donation? can you open a ticket on
> > jakartee tracker please?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 4 sept. 2019 à 15:04, Mark Struberg <st...@yahoo.de> 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 <
> rmannibucau@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 <
> >> jlmonteiro@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 <
> rmannibucau@gmail.com>
> >> wrote:
> >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> >> jlmonteiro@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
> <struberg@yahoo.de.invalid
> >>>
> >>>> 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 <
> >>>>> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>> <http://rmannibucau.wordpress.com> | Github <
> >>>>> https://github.com/rmannibucau> |
> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>> <
> >>>>>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >>>>> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 4 sept. 2019 à 15:07, Mark Struberg <st...@yahoo.de> 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 <rmannibucau@gmail.com
> >:
> >
> > @Mark: didn't change with jakarta donation? can you open a ticket on
> > jakartee tracker please?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 4 sept. 2019 à 15:04, Mark Struberg <st...@yahoo.de> 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 <
> rmannibucau@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 <
> >> jlmonteiro@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 <
> rmannibucau@gmail.com>
> >> wrote:
> >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> >> jlmonteiro@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
> <struberg@yahoo.de.invalid
> >>>
> >>>> 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 <
> >>>>> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>> <http://rmannibucau.wordpress.com> | Github <
> >>>>> https://github.com/rmannibucau> |
> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>> <
> >>>>>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >>>>> jlmonteiro@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
Posted by Mark Struberg <st...@yahoo.de>.
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 <rm...@gmail.com>:
>
> @Mark: didn't change with jakarta donation? can you open a ticket on
> jakartee tracker please?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mer. 4 sept. 2019 à 15:04, Mark Struberg <st...@yahoo.de> 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 <rmannibucau@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 <
>> jlmonteiro@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 <rm...@gmail.com>
>> wrote:
>>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> jlmonteiro@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 <struberg@yahoo.de.invalid
>>>
>>>> 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 <
>>>>> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>> <http://rmannibucau.wordpress.com> | Github <
>>>>> https://github.com/rmannibucau> |
>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>> <
>>>>>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>>>>> jlmonteiro@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
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@gmail.com>:
>
> @Mark: didn't change with jakarta donation? can you open a ticket on
> jakartee tracker please?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mer. 4 sept. 2019 à 15:04, Mark Struberg <st...@yahoo.de> 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 <rmannibucau@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 <
>> jlmonteiro@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 <rm...@gmail.com>
>> wrote:
>>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> jlmonteiro@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 <struberg@yahoo.de.invalid
>>>
>>>> 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 <
>>>>> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>> <http://rmannibucau.wordpress.com> | Github <
>>>>> https://github.com/rmannibucau> |
>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>> <
>>>>>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>>>>> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Mark: didn't change with jakarta donation? can you open a ticket on
jakartee tracker please?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 4 sept. 2019 à 15:04, Mark Struberg <st...@yahoo.de> 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 <rmannibucau@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 <
> jlmonteiro@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 <rm...@gmail.com>
> wrote:
> > Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> jlmonteiro@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 <struberg@yahoo.de.invalid
> >
> > > 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 <
> > >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> > >> > <https://rmannibucau.metawerx.net/> | Old Blog
> > >> > <http://rmannibucau.wordpress.com> | Github <
> > >> https://github.com/rmannibucau> |
> > >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >> > <
> > >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >> >
> > >> >
> > >> >
> > >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> > >> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Mark: didn't change with jakarta donation? can you open a ticket on
jakartee tracker please?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 4 sept. 2019 à 15:04, Mark Struberg <st...@yahoo.de> 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 <rmannibucau@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 <
> jlmonteiro@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 <rm...@gmail.com>
> wrote:
> > Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> jlmonteiro@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 <struberg@yahoo.de.invalid
> >
> > > 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 <
> > >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> > >> > <https://rmannibucau.metawerx.net/> | Old Blog
> > >> > <http://rmannibucau.wordpress.com> | Github <
> > >> https://github.com/rmannibucau> |
> > >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >> > <
> > >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >> >
> > >> >
> > >> >
> > >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> > >> jlmonteiro@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
Posted by David Blevins <da...@gmail.com>.
> On Sep 4, 2019, at 6:04 AM, Mark Struberg <st...@yahoo.de> 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
Posted by Mark Struberg <st...@yahoo.de>.
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 <rm...@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 <jl...@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 <rm...@gmail.com> wrote:
> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <jl...@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 <st...@yahoo.de.invalid>
> > 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 <
> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> >> > <https://rmannibucau.metawerx.net/> | Old Blog
> >> > <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> > <
> >> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >> >
> >> >
> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
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 <rm...@gmail.com>
wrote:
> go ahead
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 3 sept. 2019 à 16:41, Jean-Louis Monteiro <
> jlmonteiro@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 <rmannibucau@gmail.com
> >
> > 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 <https://twitter.com/rmannibucau> | Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >>
> >>
> >> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
> >> jlmonteiro@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 <
> >> rmannibucau@gmail.com>
> >> > wrote:
> >> >
> >> >> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> >> >> jlmonteiro@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
> >> <struberg@yahoo.de.invalid
> >> >> >
> >> >> > 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 <
> >> >> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> >> >> >> > <https://rmannibucau.metawerx.net/> | Old Blog
> >> >> >> > <http://rmannibucau.wordpress.com> | Github <
> >> >> >> https://github.com/rmannibucau> |
> >> >> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> >> >> > <
> >> >> >>
> >> >>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> >> >> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
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 <rm...@gmail.com>
wrote:
> go ahead
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 3 sept. 2019 à 16:41, Jean-Louis Monteiro <
> jlmonteiro@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 <rmannibucau@gmail.com
> >
> > 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 <https://twitter.com/rmannibucau> | Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >>
> >>
> >> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
> >> jlmonteiro@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 <
> >> rmannibucau@gmail.com>
> >> > wrote:
> >> >
> >> >> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> >> >> jlmonteiro@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
> >> <struberg@yahoo.de.invalid
> >> >> >
> >> >> > 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 <
> >> >> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> >> >> >> > <https://rmannibucau.metawerx.net/> | Old Blog
> >> >> >> > <http://rmannibucau.wordpress.com> | Github <
> >> >> >> https://github.com/rmannibucau> |
> >> >> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> >> >> > <
> >> >> >>
> >> >>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> >> >> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
go ahead
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 3 sept. 2019 à 16:41, Jean-Louis Monteiro <jl...@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 <rm...@gmail.com>
> 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 <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
>> jlmonteiro@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 <
>> rmannibucau@gmail.com>
>> > wrote:
>> >
>> >> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> >> jlmonteiro@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
>> <struberg@yahoo.de.invalid
>> >> >
>> >> > 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 <
>> >> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
>> >> >> > <https://rmannibucau.metawerx.net/> | Old Blog
>> >> >> > <http://rmannibucau.wordpress.com> | Github <
>> >> >> https://github.com/rmannibucau> |
>> >> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> >> >> > <
>> >> >>
>> >>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> >> >> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
go ahead
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 3 sept. 2019 à 16:41, Jean-Louis Monteiro <jl...@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 <rm...@gmail.com>
> 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 <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
>> jlmonteiro@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 <
>> rmannibucau@gmail.com>
>> > wrote:
>> >
>> >> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> >> jlmonteiro@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
>> <struberg@yahoo.de.invalid
>> >> >
>> >> > 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 <
>> >> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
>> >> >> > <https://rmannibucau.metawerx.net/> | Old Blog
>> >> >> > <http://rmannibucau.wordpress.com> | Github <
>> >> >> https://github.com/rmannibucau> |
>> >> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> >> >> > <
>> >> >>
>> >>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> >> >> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
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 <rm...@gmail.com>
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 <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
> jlmonteiro@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 <rmannibucau@gmail.com
> >
> > wrote:
> >
> >> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> >> jlmonteiro@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
> <struberg@yahoo.de.invalid
> >> >
> >> > 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 <
> >> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> >> >> > <https://rmannibucau.metawerx.net/> | Old Blog
> >> >> > <http://rmannibucau.wordpress.com> | Github <
> >> >> https://github.com/rmannibucau> |
> >> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> >> > <
> >> >>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >> >
> >> >> >
> >> >> >
> >> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> >> jlmonteiro@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
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@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 <jl...@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 <rm...@gmail.com> wrote:
> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <jl...@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 <st...@yahoo.de.invalid>
> > 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 <
> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> >> > <https://rmannibucau.metawerx.net/> | Old Blog
> >> > <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> > <
> >> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >> >
> >> >
> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
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 <rm...@gmail.com>
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 <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
> jlmonteiro@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 <rmannibucau@gmail.com
> >
> > wrote:
> >
> >> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> >> jlmonteiro@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
> <struberg@yahoo.de.invalid
> >> >
> >> > 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 <
> >> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> >> >> > <https://rmannibucau.metawerx.net/> | Old Blog
> >> >> > <http://rmannibucau.wordpress.com> | Github <
> >> >> https://github.com/rmannibucau> |
> >> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> >> > <
> >> >>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >> >
> >> >> >
> >> >> >
> >> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> >> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <jl...@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 <rm...@gmail.com>
> wrote:
>
>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> jlmonteiro@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 <struberg@yahoo.de.invalid
>> >
>> > 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 <
>> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
>> >> > <https://rmannibucau.metawerx.net/> | Old Blog
>> >> > <http://rmannibucau.wordpress.com> | Github <
>> >> https://github.com/rmannibucau> |
>> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> >> > <
>> >>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >> >
>> >> >
>> >> >
>> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> >> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <jl...@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 <rm...@gmail.com>
> wrote:
>
>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> jlmonteiro@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 <struberg@yahoo.de.invalid
>> >
>> > 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 <
>> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
>> >> > <https://rmannibucau.metawerx.net/> | Old Blog
>> >> > <http://rmannibucau.wordpress.com> | Github <
>> >> https://github.com/rmannibucau> |
>> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> >> > <
>> >>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >> >
>> >> >
>> >> >
>> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> >> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
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 <rm...@gmail.com>
wrote:
> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> jlmonteiro@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 <st...@yahoo.de.invalid>
> > 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 <
> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> >> > <https://rmannibucau.metawerx.net/> | Old Blog
> >> > <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> > <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >> >
> >> >
> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
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 <rm...@gmail.com>
wrote:
> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> jlmonteiro@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 <st...@yahoo.de.invalid>
> > 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 <
> >> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> >> > <https://rmannibucau.metawerx.net/> | Old Blog
> >> > <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> > <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >> >
> >> >
> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <jl...@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 <st...@yahoo.de.invalid>
> 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 <
>> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
>> > <https://rmannibucau.metawerx.net/> | Old Blog
>> > <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>> >
>> >
>> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <jl...@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 <st...@yahoo.de.invalid>
> 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 <
>> rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
>> > <https://rmannibucau.metawerx.net/> | Old Blog
>> > <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>> >
>> >
>> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
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 <st...@yahoo.de.invalid>
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 <rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
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 <st...@yahoo.de.invalid>
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 <rmannibucau@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 <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> jlmonteiro@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
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@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 <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <jl...@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
Posted by Mark Struberg <st...@yahoo.de>.
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 <da...@gmail.com>:
>
>> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau <rm...@gmail.com> 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
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <da...@gmail.com>:
>
>> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau <rm...@gmail.com> 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
Posted by David Blevins <da...@gmail.com>.
> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau <rm...@gmail.com> 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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 4 sept. 2019 à 11:16, Jean-Louis Monteiro <jl...@tomitribe.com>
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 <rm...@gmail.com>
> 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 <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <
>> jlmonteiro@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 <da...@gmail.com>
>> > wrote:
>> >
>> >> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <
>> rmannibucau@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 <
>> >> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 4 sept. 2019 à 11:16, Jean-Louis Monteiro <jl...@tomitribe.com>
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 <rm...@gmail.com>
> 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 <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <
>> jlmonteiro@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 <da...@gmail.com>
>> > wrote:
>> >
>> >> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <
>> rmannibucau@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 <
>> >> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
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 <rm...@gmail.com>
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 <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <
> jlmonteiro@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 <da...@gmail.com>
> > wrote:
> >
> >> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <rmannibucau@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 <
> >> jlmonteiro@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
Posted by David Blevins <da...@gmail.com>.
> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau <rm...@gmail.com> 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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
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 <rm...@gmail.com>
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 <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <
> jlmonteiro@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 <da...@gmail.com>
> > wrote:
> >
> >> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <rmannibucau@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 <
> >> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
No I guess it was right, "that are" ;) = fork @G only when we need to
change some impl/default provider.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <jl...@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 <da...@gmail.com>
> wrote:
>
>> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <rm...@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 <
>> jlmonteiro@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
No I guess it was right, "that are" ;) = fork @G only when we need to
change some impl/default provider.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <jl...@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 <da...@gmail.com>
> wrote:
>
>> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <rm...@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 <
>> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
> 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 <da...@gmail.com>
wrote:
> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <rm...@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 <
> jlmonteiro@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
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
> 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 <da...@gmail.com>
wrote:
> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <rm...@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 <
> jlmonteiro@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
Posted by David Blevins <da...@gmail.com>.
> On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <rm...@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 <jl...@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
Posted by Mark Struberg <st...@yahoo.de>.
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 <rm...@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 <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <jl...@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
Posted by David Blevins <da...@gmail.com>.
> On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <rm...@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 <jl...@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
Posted by Romain Manni-Bucau <rm...@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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <jl...@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
Posted by Romain Manni-Bucau <rm...@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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <jl...@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
>