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