No I guess it was right, "that are" ;) = fork @G only when we need to change some impl/default provider.


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


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



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