Hi, Bumping this thread up Not yet at the point where I'm clear on what path to use regarding the API, but it's been a while so I wanted to provide some status.
You may have noticed the VOTE thread going on regarding TomEE 9.0.0-M2. This is the first real milestone for TomEE with the actual source code migrated to jakarta. It means that full packaged distributions (WebProfile, MicroProfile, Plume and Plus ZIP/TAR.GZ) should be mostly working. But the application composer, the JUnit support, even Arquillian are now fully migrated. We had to do a lot of shading/relocation of certain libraries on our side because libraries were not yet ready. We've worked very hard but we are finally looking good. We still have a few failures on our build to solve, but the platform TCK + CDI + BVal are looking good with less than 50 failures of 35K tests. Please remember this is a milestone and we are all still working on it. Any feedback is appreciated and will help. We started also upgrading our MicroProfile support to the latest one. So far Config, Health and Metrics are fully migrated and passing the TCK. We are actively working on MicroProfile JWT. And we'll be proceeding with the others when possible. If you haven't done it yet, please try it and feel free to vote. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Thu, May 26, 2022 at 1:28 PM Jean-Louis Monteiro < [email protected]> wrote: > 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 <[email protected]> > 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 < >> [email protected]> 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 >> >> > >
