Hi Swell; You answer and thoughts are more than welcome.
For the moment we use the same approach, exclude APIs where the IMPL is packaged in (Mail and Faces at least). Yes Jakarta also provides an Uber jar, and regardless of the fact it is outdated or not, it has the same issue. Using the Uber jar automatically brings use Sun Mail implementation and Faces Mojorra implementation. i believe there could be : > > - one up to date bom for all api only. > Does not seem to solve the issue as the dependency for the API would also bring the implementation because it's one jar only and one dependency only. > - one uber apis jar per TomEE flavor. > Yes I was thinking about this one as well. > - separated original implementation jars from providers. > We would need to dig into the specifics to see if that is possible and how. Yes feel free to submit a PR and ping us on the mailing list to get feedback and reviews. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Wed, Jul 6, 2022 at 11:27 AM Swell <souheil.sul...@gmail.com> wrote: > 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 > > >> > > >> > > > > > > > > >
