Hi, regarding the APIs i hope that my answer is not off-topic, what I believe is someone using our uber api jar would want the apis without impl, even for mail and faces. if i were to use it i would want implementations separated on their own official jar, but not fused together.
as a note there exist a bom for jakarta ee but its outdated https://mvnrepository.com/artifact/jakarta.platform/jakarta.jakartaee-bom/9.1.0 the official one provided lacks the minor fixes (e.g points to EJB 4.0.0 instead of 4.0.1, to cite only one of the problems) i believe there could be : - one up to date bom for all api only. - one uber apis jar per TomEE flavor. - separated original implementation jars from providers. we provide an up-to-date jakarta ee javadoc to cover the lack (which i updated the api versions), in the same idea would it be ok for TomEE project to provide both such a BOM and uber apis jar ? (which i could update side by side with javadoc) -- Swell On Mon, 4 Jul 2022 at 10:50, 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 fullyHi, > 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 > >> > >> > > > > >
