DISCUSS geronimo-security_1.0_spec content unclear

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

DISCUSS geronimo-security_1.0_spec content unclear

Jean-Louis Monteiro-2
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.


and 


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?
Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

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

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


Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <[hidden email]> 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.


and 


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?
Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

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

LieGrue,
strub


> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <[hidden email]>:
>
> 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 <[hidden email]>
> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

Jean-Louis Monteiro-2
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.


On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]>
> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

Romain Manni-Bucau


Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <[hidden email]> 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.


On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]>
> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

Jean-Louis Monteiro-2
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.


On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau <[hidden email]> wrote:
Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <[hidden email]>
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 <[hidden email]>
> 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 <
>> [hidden email]>:
>> >
>> > 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 <
>> [hidden email]>
>> > 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
>> >>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

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

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


Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <[hidden email]> 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.


On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau <[hidden email]> wrote:
Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <[hidden email]>
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 <[hidden email]>
> 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 <
>> [hidden email]>:
>> >
>> > 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 <
>> [hidden email]>
>> > 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
>> >>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

Jean-Louis Monteiro-2
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


On Tue, Sep 3, 2019 at 4:37 PM Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>
> wrote:
>
>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> [hidden email]>
>> 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 <[hidden email]
>> >
>> > 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 <
>> >> [hidden email]>:
>> >> >
>> >> > 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 <
>> >> [hidden email]>
>> >> > 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
>> >> >>
>> >>
>> >>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

Romain Manni-Bucau
go ahead

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


Le mar. 3 sept. 2019 à 16:41, Jean-Louis Monteiro <[hidden email]> 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


On Tue, Sep 3, 2019 at 4:37 PM Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>
> wrote:
>
>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> [hidden email]>
>> 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 <[hidden email]
>> >
>> > 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 <
>> >> [hidden email]>:
>> >> >
>> >> > 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 <
>> >> [hidden email]>
>> >> > 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
>> >> >>
>> >>
>> >>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

Jean-Louis Monteiro-2
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

On Tue, Sep 3, 2019 at 4:49 PM Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>
> 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 <
>> [hidden email]>
>> 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 <
>> [hidden email]>
>> > wrote:
>> >
>> >> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> >> [hidden email]>
>> >> 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
>> <[hidden email]
>> >> >
>> >> > 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 <
>> >> >> [hidden email]>:
>> >> >> >
>> >> >> > 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 <
>> >> >> [hidden email]>
>> >> >> > 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
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

David Blevins-2
In reply to this post by Romain Manni-Bucau
> On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

Jean-Louis Monteiro-2
> 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

On Tue, Sep 3, 2019 at 8:07 PM David Blevins <[hidden email]> wrote:
> On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

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


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


Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <[hidden email]> 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

On Tue, Sep 3, 2019 at 8:07 PM David Blevins <[hidden email]> wrote:
> On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

Jean-Louis Monteiro-2
so for instance activation and javamail would stay in Geronimo Specs and let's say @Inject would be Eclipse?


On Wed, Sep 4, 2019 at 11:11 AM Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>
> wrote:
>
>> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <[hidden email]>
>> 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 <
>> [hidden email]> 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
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

Romain Manni-Bucau
exactly.
Think it makes sense to keep it hosted to change this value even if system props/SPI enable to switch it since it enables to make fatjars smooths without configs and to ensure we load the right default but it is really a single string so can be discussed.

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


Le mer. 4 sept. 2019 à 11:16, Jean-Louis Monteiro <[hidden email]> a écrit :
so for instance activation and javamail would stay in Geronimo Specs and let's say @Inject would be Eclipse?


On Wed, Sep 4, 2019 at 11:11 AM Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>
> wrote:
>
>> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <[hidden email]>
>> 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 <
>> [hidden email]> 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
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

Mark Struberg
In reply to this post by Romain Manni-Bucau
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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]> wrote:
> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <[hidden email]>
> 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 <[hidden email]>
> > 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 <
> >> [hidden email]>:
> >> >
> >> > 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 <
> >> [hidden email]>
> >> > 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
> >> >>
> >>
> >>

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

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

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


Le mer. 4 sept. 2019 à 15:04, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]> wrote:
> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <[hidden email]>
> 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 <[hidden email]>
> > 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 <
> >> [hidden email]>:
> >> >
> >> > 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 <
> >> [hidden email]>
> >> > 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
> >> >>
> >>
> >>

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

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

LieGrue,
strub

> Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau <[hidden email]>:
>
> @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 <[hidden email]> 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 <[hidden email]
>>> :
>>>
>>> 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 <
>> [hidden email]> 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 <[hidden email]>
>> wrote:
>>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> [hidden email]>
>>> 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 <[hidden email]
>>>
>>>> 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 <
>>>>> [hidden email]>:
>>>>>>
>>>>>> 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 <
>>>>> [hidden email]>
>>>>>> 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
>>>>>>>
>>>>>
>>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

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

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


Le mer. 4 sept. 2019 à 15:07, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> @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 <[hidden email]> 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 <[hidden email]
>>> :
>>>
>>> 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 <
>> [hidden email]> 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 <[hidden email]>
>> wrote:
>>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> [hidden email]>
>>> 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 <[hidden email]
>>>
>>>> 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 <
>>>>> [hidden email]>:
>>>>>>
>>>>>> 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 <
>>>>> [hidden email]>
>>>>>> 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
>>>>>>>
>>>>>
>>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS geronimo-security_1.0_spec content unclear

Jean-Louis Monteiro-2
I'd like to certify some of them if possible of course. 

Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
> >:
> >
> > @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 <[hidden email]> 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 <
> [hidden email]
> >>> :
> >>>
> >>> 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 <
> >> [hidden email]> 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 <
> [hidden email]>
> >> wrote:
> >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> >> [hidden email]>
> >>> 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
> <[hidden email]
> >>>
> >>>> 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 <
> >>>>> [hidden email]>:
> >>>>>>
> >>>>>> 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 <
> >>>>> [hidden email]>
> >>>>>> 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
> >>>>>>>
> >>>>>
> >>>>>
> >>
> >>
>
>
12