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 >> >>
