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:21:47 GMT
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 <jlmonteiro@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 <rmannibucau@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 <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