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