@Jonathan I followed the Eclipse Transformer steps [0], I found a small typo and opened a PR [1].
The latest master for apache-tomee-webprofile-8.0.2 started without any error. When I tried to access the manager or the default /webapps, they didn't work, I guess we can apply the transformer too. I have a couple of questions: 1) What are the criteria we need to choose to know which javax.* packages need to be migrated to Jakarta? As I understand the packages migration can be configured via: https://github.com/apache/tomee/blob/master/transformer/jakarta-renames.properties For example, when I decompiled jaxb-runtime-2.3.2.jar/com/sun/xml/bind/api/Bridge.class I notice that not all the packages were migrated: package com.sun.xml.bind.api; import com.sun.istack.NotNull; import com.sun.istack.Nullable; import com.sun.xml.bind.v2.runtime.BridgeContextImpl; import com.sun.xml.bind.v2.runtime.JAXBContextImpl; import jakarta.xml.bind.JAXBException; import jakarta.xml.bind.Marshaller; import jakarta.xml.bind.Unmarshaller; import jakarta.xml.bind.attachment.AttachmentMarshaller; import jakarta.xml.bind.attachment.AttachmentUnmarshaller; import java.io.InputStream; import java.io.OutputStream; import org.w3c.dom.Node; import org.xml.sax.ContentHandler; //Not migrated: import javax.xml.namespace.NamespaceContext; import javax.xml.stream.XMLStreamReader; import javax.xml.stream.XMLStreamWriter; import javax.xml.transform.Result; import javax.xml.transform.Source; 2) I see that you already have a branch with the examples translated to Jakarta but as far I understand, migration to create the Jakarta EE 9 API jar is a prerequisite. I'm happy to take https://issues.apache.org/jira/browse/TOMEE-2802 in order to make a snapshot release but then question 1) arises again. The migrated version, where should we version it? on a new SVN Branch like https://svn.apache.org/repos/asf/tomee/jakartaee-api/trunk/? [0] http://tomee.apache.org/tomee-8.0/docs/jakartaee-9/index.html [1] https://github.com/apache/tomee/pull/635 @Gilberto I think the proposed approach with the transformation will actually facilitate the end-user the migration of EE apps to JakartaEE because the intention is that the application server will do the transformation for them on the fly. I see that Tomcat took the approach you suggested with 10.x [2] and there is a work on progress over a migration tool to aid this process [3]. This last point reinforce the fact that there are people that will prefer to upgrade their servlet container (Tomcat) or their JakartaEE server (TomEE) with their existing applications. As far as I recall, currently, you can keep JDK8->TomEE8 but also JDK11->TomEE8.x. I don't understand how the JDK11 -> JAKARTA9-> TomEE9 would not work with the Transformer approach. [2] https://tomcat.apache.org/download-10.cgi [3] https://github.com/apache/tomcat-jakartaee-migration El mar., 21 abr. 2020 a las 13:06, Gilberto Caetano de Andrade (< [email protected]>) escribió: > > > On 2020/04/21 19:00:54, Gilberto Caetano de Andrade <[email protected]> > wrote: > > Hi, > > > > On 2020/04/16 13:23:26, Jonathan Gallimore <[email protected]> > 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! > > > I mean I prefer stay with JDK8->JAKARTA8->TomEE8 for my current projects. > For the new ones I prefer JDK11 -> JAKARTA9-> TomEE9. > > Sorry! > > > 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 > > > > > > -- Atentamente: César Hernández.
