Hi everyone! I hope all is well with you all!! Jonathan, I see the project with few resources (Sorry for not helping much here!) and a lot sub-project to take care - do you understand? So, I would focus in, for example, build and certify tomEE on the Jakarta Web Profile (or minor one if the jakarta project create one) I known my vision is simplistic, but I think and see that the project would gain more engagement and resources with fewer sub-project(JSR and now JESP[1]), taking the direction of micronaut, spring-boot, dropwizard, etc.
Regards, Gilberto [1] https://jakarta.ee/about/jesp/ On 2020/04/28 11:43:57, Jonathan Gallimore <[email protected]> wrote: > 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 < > [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! > > > > 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 > > > > > >
