Hi,
quick feedback before getting into more details
A/ or this alternative
Geronimo Specs were not available in the Jakarta namespace. We are starting
to move some of them like Activation and Mail. Other than that, we mainly
have Eclipse produced APIs for Jakarta.
I'm not sure if we want to migrate our Geronimo Specs jars or use the stock
Jakarta APIs. Important note, if we do, we may not need the jakartaee-api
because there is already a Uber jar for Jakarta within the different
profiles. Should we get our user to use it as provided. And on our side,
should we create just a bom in our project and get the job done?
Some APIs are also more or less implementations and vice versa. This is the
case for mail, faces, and some more as you mentioned. I'm fine including
Mail provider + Geronimo Mail spec in the jakartaee-api jar but mind that
in the past some users wanted to use Sun implementation and it will be
harder
D/ what about inconsistencies like ...
Some implementations can be switched, for example Faces. Which is also a
mess because API and IMPL are linked together. I had previously the Faces
API but of course you need the implementation as well, same as for mail.
But Plume uses Mojorra. So we are in the situation where we need to pick
one or the other.
B/ or this alternative ...
Tomcat classifier because we don't want to cheap with APIs already provided
in Tomcat with the risk of not being fully aligned. So we use Tomcat APIs.
Should we go the way around and remove Tomcat APIs from the final
distribution and get rid of the Tomcat classifier?
Note sure if my reply is clear, hopefully it helps.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Thu, May 26, 2022 at 3:23 AM David Blevins
wrote:
> Thanks so much for this. I even started creating one myself early this
> morning, ... then the rest of the day happened LOL
>
> > On May 25, 2022, at 1:56 PM, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
> >
> > Here it is
> >
> https://gist.github.com/jeanouii/9bb6c14bdde227e2fed83fd73db3a646/revisions
>
> Looks like we've yanked out Faces, JSTL, Mail, etc. I suspect we're
> trying to hit the line of not including APIs that are implementations. The
> real trick is even HttpServlet is completely dependent on the servlet
> container in the same way Faces, Mail, JSTL, etc are dependent on their
> implementations. I'm not too sure if Activation is also considered an
> implementation as well -- I'm not sure off-hand if there is a separate
> implementation jar.
>
> I know we didn't include mail in our javaee-api jar, so excluding is
> following that logic. I also know we have the
> jakartaee-api-9.1-M2-SNAPSHOT-tomcat.jar, which cuts out everything very
> close to the way we've now done it in jakartaee-api-9.1-M2-SNAPSHOT.jar
>
> How do we want to handle this?
>
> Seems our options are:
>
> A. Leave jakartaee-api-X.jar and jakartaee-api-X-tomcat.jar nearly
> identical in missing many specs. There is no uber jar people can compile
> against that has most everything. People would need to discover which
> specs are missing and pull them in individually.
>
> B. Eliminate having two jars, there is now just
> jakartaee-api-X-tomcat.jar (which we call jakartaee-api-X.jar). There is
> no uber jar people can compile against that has most everything. People
> would need to discover which specs are missing and pull them in
> individually.
>
> C. Do what we did with javaee-api.jar and leave mail out while including
> other impls. There is something close to an uber, but still not quite as
> identical to the jakartaee-api jar produced at Eclipse using the Eclipse
> impls.
>
> D. Reverse our stance on the mail thing. There would be jakartaee-api
> that contained everything including mail and it would be identical to the
> jakartaee-api jar produced at Eclipse using the Eclipse impls.
>
> Not sure where I sit on this spectrum yet, throwing it out so we all can
> think in parallel.
>
> Is it at all possible to get a similar diff for the "-tomcat" jar?
>
>
> -David
>
>
