On Tue, Apr 28, 2020 at 3:42 AM Cesar Hernandez <[email protected]> wrote:
> @Jonathan > I followed the Eclipse Transformer steps [0], I found a small typo and > opened a PR [1]. > Thanks, I've merged that in. > > 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. > Good point. > > 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: > > //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; > We're almost certainly missing some rules. This is a useful source for the package renames: https://www.tomitribe.com/jakarta/ns/poll/vote - click on specific javax packages to see the renames. Any dependent namespaces will also be selected (try javax.xml.soap, for example). Its definitely not a straight rename "javax" to "jakarta" everywhere, however. I'd need to check on these specific cases. > 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. > Correct. > 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/? > I'm inclined to move it to Git. If you agree, do you want to create a new VOTE thread for that? I believe the process itself is self-service, and you would be able to do that. > > > [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. > I did Gilberto's mail on this thread - I'll reply to that separately. Jon > > > [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. >
