Hi Gilberto Thanks for your post! I appreciate the you taking the time to post and give your views.
> 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. Can you elaborate on what you mean with "this way you will [be] obligated to stay with all of them"? > Reading about Jakarta EE 9 I've discovered that the goal is JDK11 -> JAKARTA9 and of course the rename thing. That's not quite right. Java/JDK 8 is still the base for Jakarta EE 9. The key difference between EE8 and EE9 is the package rename. You can use JDK 11 with TomEE 8 today, and if you find something doesn't work, that is a bug, and we'd want to fix it. We'll be targeting JDK 8 and 11 for Jakarta EE 9. > But the main message is you do not need be backwards compatible (you can if you wish). I'd call this out as the key part of your post. You're correct, implementations do *not* need to be backwards compatible with Jakarta EE 8, and they do not need to allow or be forgiving of any code that references the old javax packages. The question we need to answer as a community is: do we want to allow backwards compatibility? I'll very clearly state my own personal view is "yes", for the following reasons: 1. One way or another, we will need to support EE 8 for a long time. TomEE has a wide range of users, some will find the migration easy, and some will take multiple years to migrate their applications. One option is to run parallel branches for EE8 and EE9, but it is very unlikely that changes will be mergeable across the two. We already have 3 active branches, and 4 flavours of TomEE for each branch. Picking the one you want is already a challenge. 2. One of the principals of TomEE is for the server to bend to fit the user, not the other way around. Want to bring deployment descriptors from another app server? No problem, we'll try and parse them and do the right thing. I think breaking backwards compatibility would not be particularly friendly to our consumers. 3. All of TomEE's competitors are likely to have backwards compatibility. I'd be interesting in hearing if others are in favour of dropping backwards compatibility. I'm happy to look at other options to the Transformer, of course, but I think it merits investigation, as it potentially gives us some quick wins. Jon On Tue, Apr 21, 2020 at 8:00 PM Gilberto Caetano de Andrade < gilbert...@gmail.com> wrote: > 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 > > >
