geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: DISCUSS geronimo-security_1.0_spec content unclear
Date Wed, 04 Sep 2019 09:10:46 GMT
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 <david.blevins@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
>>
>>

Mime
View raw message