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 <jlmonte...@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 <rmannibu...@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 < >> jlmonte...@tomitribe.com> >> a écrit : >> >> > > This is my current thinking as well; maintain apis that are impls, use >> > the EPL version otherwise. >> > I believe you meant "that are not impls ..." >> > >> > I'll make the changes on the javaee-api jar >> > >> > -- >> > Jean-Louis Monteiro >> > http://twitter.com/jlouismonteiro >> > http://www.tomitribe.com >> > >> > >> > On Tue, Sep 3, 2019 at 8:07 PM David Blevins <david.blev...@gmail.com> >> > wrote: >> > >> >> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau < >> rmannibu...@gmail.com> >> >> wrote: >> >> > >> >> > If we still can't reuse jakata artifacts (their license is ok and >> there >> >> is no impl reference inside so we should just use them, right?) it >> sounds >> >> natural >> >> >> >> This is my current thinking as well; maintain apis that are impls, use >> >> the EPL version otherwise. >> >> >> >> We do have a handful of EPL dependencies, such as ECJ which Tomcat >> itself >> >> uses. Also as more projects like CXF switch over using the Jakarta >> >> versions, our excludes just get harder to manage. >> >> >> >> >> >> -David >> >> >> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro < >> >> jlmonte...@tomitribe.com> a écrit : >> >> > Hi all, >> >> > >> >> > I was digging into some other specifications and see what would pass >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content >> actually >> >> mixes 2 specifications. >> >> > >> >> > https://github.com/eclipse-ee4j/security-api >> >> > >> >> > and >> >> > >> >> > https://github.com/eclipse-ee4j/jaspic >> >> > >> >> > I thought the initial intent was to create a specific artifact per >> >> specification. >> >> > Mixing them is a bit annoying from a certification perspective. >> >> > It's also not clean because in Tomcat for instance, there is already >> >> jaspic API so it becomes a duplicate. >> >> > >> >> > Would it be possible to split them up in 2 artifacts? >> >> > >> >> > -- >> >> > Jean-Louis Monteiro >> >> > http://twitter.com/jlouismonteiro >> >> > http://www.tomitribe.com >> >> >> >> >> >
