API and Implementations dependencies in TomEE

[Swell <so...@gmail.com>]

Hi everyone,

i wanted to discuss whether it was possible or desirable to switch some of
the project's API and Impl dependencies.
i'll try to be as concise as possible and polite to people doing already a
lot of good to the project. so please forgive in advance any heavy idea
from me or my bad english wording, no hurt intended.

Short story, with the mailing list approval, i wanted to test the
feasibility:
* Replace Activation API and Mail API from Geronimo by their Jakarta EE API
counterpart, and keep Geronimo Impl with a fallback (replace by com.sun
implementations for these two only if needed, Geronimo in attic, etc.)
* Replace JCache API from Geronimo by JCache API from
https://mvnrepository.com/artifact/javax.cache/cache-api/1.1.1 (independent
of implementation)
* Replace Geronimo Microprofile (2.0) by Microprofile 4.1 from SmallRye on
branch 8.x (heavy)
* Replace org.apache.tomee/jakartaee-api by its counterpart from Jakarta EE
API (heavy, if tomcat has deltas with or lacks some implementation, detect
them and ask the mailing list again for desired path to take)

Surely not all of them are desirable, may be risky with no new functional
feature added (except for MP 4.1 on branch 8).
That said, if Geronimo goes attic we need a fallback and the sooner an API
switch is tested the sooner we know our options.

With me suggesting the changes, i might also try to do the multiple PR
needed on branch 8, 9, and maybe 10 when it comes.

if these changes are desirable, I might have questions on the road,
Like what is the implementation of JCache ? is it linked to apache commons
jcs cache? or EHCACHE?

Looking forward to your feedback,
Thanks for your time.

--
Swell
--
note to self
* EHCache looks impacted or sensitive to the javax/jakarta namespace
change,

Long story:
TomEE currently depends on Activation API and Mail API taken from Geronimo
Impl.
Likewise, we depend on Tomcat for Servlet API and such instead of Jakarta
EE API.
This gives us more flexibility to not implement all Jakarta EE api, if, for
some reason, the chosen implementation lacks a part of it.
I believe this is why we find copies of the Jakarta EE API copied within
all the projects that uses them.
like :
* org.jboss.spec
* org.apache.geronimo.specs
* org.apache.tomee/jakartaee-api

while it's ok for PROs to have applications tied to the "Server API"
(guaranties the API is implemented)
some other folks or firms might want to have their app not tied to a
particular server and linked to the Jakarta EE API, to easily switch.

Maybe it can attract more users to go TomEE, with an easier switch, if we
have TomEE depending on Jakarta EE API from
"jakarta.platform/jakarta.jakartaee-api" instead of
"org.apache.tomee/apache-tomee",