I think I left too many important details out, leaning on prior discussions.
+1 trillion on avoiding two branches. Worse is they wouldn't actually be "branches" but two different codebases where any patching to them both would have to be always done by hand. Here's an attempt at clearer problem statement and potential solution being prototyped. PROBLEM Effectively, the second we do the rename in source we can no longer backport patches using git rebase/merge/diff, etc and the cost of maintenance on this project doubles. Whatever pace we're at now will be twice as slow. On top of this we're still some months away from Jakarta EE 8 compliance, which was released in 2019. If we go down the traditional path, we're probably looking at Jakarta EE 8 sometime in 2021 (maybe early) and Jakarta EE 9 perhaps mid or late 2021. In this trajectory the most optimistic outcome is despite the 2x slowdown we manage to maintain the pace of being perpetually 12-15 months behind all the other implementations. POTENTIAL SOLUTION (PROTOTYPED) There's a new bytecode transformation project, Eclipse Transformer (https://github.com/eclipse/transformer/issues), which has the goal of providing backwards compatibility to old code by migrating it from javax to jakarta in bytecode, no need to edit source. We've plugged it in to master (TomEE 8) and with some effort we are able to get a server using entirely `jakarta.foo` APIs that boots and runs a JSP. As Jakarta EE 8 and Jakarta EE 9 are identical and only differ by namespace, this technique means we can keep master focused on Jakarta EE 8 and eventually passing that TCK while getting Jakarta EE 9 TCK compliant binaries from the same branch for free. The potential benefits: - Allows us to catch up, effectively gaining a year. The early 2021 timeline would be both Jakarta EE 8 and Jakarta EE 9 compliant. Jakarta EE 9 is due to release in September. We could potentially be certified just a few months after. - Allows us to offer a proven and tested backwards compatibility solution long-term. When we do switch the codebase over, we can reverse the renaming and produce a version of TomEE 9, 10, etc under the javax namespace that can run the older apps. - We would be able to focus on Jakarta EE 10. Under the "problem" trajectory we'll be focused on Jakarta EE 9 and be mid conflict-merge hell while everyone else is focused on adding new features to Jakarta EE 10. In this path we could be done with all that and have time to actually participate in pioneering some Jakarta EE 10 features. We could be releasing milestones of our ideas for Jakarta EE 10 during that time making us a place early adopters can try out potential new features. We may or may not get all the benefits we're hoping to get, but so far the prototype looks really good and there are no showstoppers yet. PROTOTYPED BINARIES AND POTENTIAL VERSIONS One of the things Thomas mentions "could we produce TomEE 8 and 9 from master?" is a question I also have. Right now we're producing the following binaries from master: miles:~/work/apache/tomee/tomee/apache-tomee/target 08:42:31 $ find *.zip apache-tomee-microprofile-8.0.3-SNAPSHOT.zip apache-tomee-microprofile-jakartaee9-8.0.3-SNAPSHOT.zip apache-tomee-plume-8.0.3-SNAPSHOT.zip apache-tomee-plume-jakartaee9-8.0.3-SNAPSHOT.zip apache-tomee-plus-8.0.3-SNAPSHOT.zip apache-tomee-plus-jakartaee9-8.0.3-SNAPSHOT.zip apache-tomee-webprofile-8.0.3-SNAPSHOT.zip apache-tomee-webprofile-jakartaee9-8.0.3-SNAPSHOT.zip The plugin Jon wrote basically adds "jakartaee9-" to the file name to signify that binary supports only `jakarta` APIs and namespace. It perhaps feels a little off that they will get final "8.0.3" version numbers when in reality they'll just be beta or milestone quality of Jakarta EE 9. It's also strange they say "8" at all. This could be nice if Maven would allow it: miles:~/work/apache/tomee/tomee/apache-tomee/target 08:42:31 $ find *.zip apache-tomee-microprofile-8.0.3-SNAPSHOT.zip apache-tomee-microprofile-9.0.0-M1-SNAPSHOT.zip apache-tomee-plume-8.0.3-SNAPSHOT.zip apache-tomee-plume-9.0.0-M1-SNAPSHOT.zip apache-tomee-plus-8.0.3-SNAPSHOT.zip apache-tomee-plus-9.0.0-M1-SNAPSHOT.zip apache-tomee-webprofile-8.0.3-SNAPSHOT.zip apache-tomee-webprofile-9.0.0-M1-SNAPSHOT.zip If Maven didn't allow it we could still potentially publish them on the site this way. Anyway, technical challenges aside how we might handle it is keep the Jakarta EE 9 binaries in milestone right up util the moment that we're able to pass the Jakarta EE 8 and 9 TCKs (which are identical, minus namespace change). When we're passing we finally do cut master over to be completely TomEE 9 / Jakarta EE 9. -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jun 11, 2020, at 12:42 AM, Thomas Andraschko <andraschko.tho...@gmail.com> > wrote: > > From a user perspective i would really suggest to make TomEE8 = JakartaEE8, > TomEE9 = JakartaEE9, .... > I think its to much work to maintain 2 branches. Maybe it would be a good > idea to create a TomEE8 and TomEE9 from master? > > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> > Virenfrei. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > Am Do., 11. Juni 2020 um 06:37 Uhr schrieb Vano Beridze <vanua...@gmail.com >> : > >> I think TomEE 8 should support Jakarta EE 8. If this important milestone is >> hit, then it will be much easier to transition to Jakarta EE 9. >> >> Vano >> >> On Thu, Jun 11, 2020, 4:14 AM David Blevins <david.blev...@gmail.com> >> wrote: >> >>> All, >>> >>> There will be a Jakarta EE 9 milestone release on June 23rd. The release >>> announcement will feature Eclipse GlassFish milestone build and roadmap. >>> Other implementations will be included in the announcement if they would >>> like. >>> >>> What we would need to supply to be included would be: >>> >>> - Roadmap: Version and quarter. What TomEE version will we support the >>> jakarta namespace, when will a milestone of it be available? >>> - Link: to a milestone, beta, etc that supports the `jakarta` namespace >>> if available. (Optional) >>> >>> The question for us all is, do we want to be included in either or both >> of >>> those? If yes, these are the dates we need to hit: >>> >>> - Roadmap: Next Wednesday >>> - Link: Release vote up no later than Friday June 19th and complete >>> Monday 22nd. >>> >>> Our status with the bytecode transformation work is the `jakarta` >>> transformed server boots and serves a JSP. This would be enough for the >>> milestone. We would just need to get a TomEE 8 release up for vote by >> next >>> week and not let it drag on like we normally do -- we'd have to be fast. >>> >>> In terms of what the roadmap status could be, here's an option: >>> >>> - Version: Apache TomEE 8, support for both javax and jakarta namespaces >>> - Quarter: Q3, 2020 >>> >>> - Version: Apache TomEE 9, support for jakarta namespace >>> - Quarter: TBD >>> >>> The important thing to keep in mind is we can always give a tentative >> plan >>> and change our minds later. If we communicate no status because we >> cannot >>> agree on what that status should be, then it just means that other major >>> projects would be there but us. >>> >>> We haven't had too much discussion on what version we would do all this >>> in. For example, we could potentially support Jakarta EE 8 and 9 in >> TomEE >>> 9 like we are potentially are in TomEE 8. >>> >>> The important thing to always remember when communicating status in a big >>> announcement is to be a bit conservative. It's easier to surprise people >>> than to disappoint people. >>> >>> >>> Thoughts? >>> >>> >>> -- >>> David Blevins >>> http://twitter.com/dblevins >>> http://www.tomitribe.com >>> >>> >>
smime.p7s
Description: S/MIME cryptographic signature
