Hi, On 2020/04/16 13:23:26, Jonathan Gallimore <jonathan.gallim...@gmail.com> wrote: > Hi All, > > You may be aware that as part of the Jakarta EE 9 release later this year, > the various APIs provided in TomEE will be shifting from javax namespaces > to jakarta. > > I'm currently researching the use of the Eclipse Transformer project ( > https://projects.eclipse.org/projects/technology.transformer) to translate > both the TomEE server itself, and the source code for the examples. > > So far, I have a converted javaee-api.jar, and a Jakarta-ized version of > TomEE that boots. There's *lots* that doesn't work at the present moment, > but I'm expecting to have the moviefun example running fairly soon - that > covers EJB, Servlets, JSPs, JPA. The REST version of the sample also covers > JAX-RS too. > > I'm aware that there's also a migration tool that Tomcat have been working > on too, and will be looking at. > > We ought to have some discussion about the approach here - in my mind there > are some high-level goals: > > * Try and maintain a single codebase for javax and jakarta. I my opinion is the worst idea. TomEE has had a history of spread projects and this way you will obligated to stay with all of them.
>It's tempting to fork master and embark on a massive renaming exercise. I would like to suggest another way for the TomEE project with this great opportunity (please consider my words, I'm not expert in lib, just user here ok!) Reading about Jakarta EE 9 I've discovered that the goal is JDK11 -> JAKARTA9 and of course the rename thing. But the main message is you do not need be backwards compatible (you can if you wish). My suggestion is to follow the train like JDK11 -> JAKARTA9-> TomEE9 The TomEE9 branch (I suggest it be the master one) will suffer the rename task and prune the legacy project/dependency one Hardly I will upgrade or port my ee projects to jakata9 - I'm having a hard time to update to jdk11 :) I prefer stay with JDK8->TomEE8! Regards, Gilberto PS.: Thank you all for great project >That's complex as we'd need to do that for various dependencies as well, who >may > also have other branches and timelines. Having two codebases also means > that any changes need to be applied twice, and with renamed packages, its > unlikely the git merging or cherry-picking will work. > > * Be backwards compatible - One goal I had in my mined, is that if you have > an application that uses javax, you'd probably like to be able to run it on > a new Jakarta EE server. There are some options here - I quite like the > idea of running the Transformer as a javaagent, so any applications > deployed using the old namespaces are converted on the fly at the bytecode > level. > > * Tooling - I wonder what tooling we could potentially provide? One thought > I had was a Maven plugin that can transform a war/ear file for you as part > of a build. > > Anyway, just wanted to give a heads-up on the research. Any thoughts / > discussions / questions are encouraged. > > Jon >
