Forgot the big thank you to everyone and special kudos to Richard. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
On Mon, Jul 4, 2022 at 10:49 AM Jean-Louis Monteiro < jlmonte...@tomitribe.com> wrote: > 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 < > jlmonte...@tomitribe.com> 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 <david.blev...@gmail.com> >> 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 >>> >>> >> >>
