Thank you all for your feedbacks, comparison pages sent for review: + https://github.com/apache/tomee/pull/854 + https://github.com/apache/tomee/pull/855
you might want those two "per-version" comparison pages to be without the tables for "flavors" and "implementations" since these tables also are in the "main" comparison page in the website PR: https://github.com/apache/tomee-site-generator/pull/37 i believe this version is closer to expectations, with room for improvements, open to suggestions, Swell On Tue, 12 Apr 2022 at 21:04, David Blevins <david.blev...@gmail.com> wrote: > Sounds awesome, everyone. > > Total side note. I cannot express how much I love seeing this much > engagement and collaboration. Often times PRs don't get any feedback at > all and sit for months. It's really fantastic to see activity like this. > > > -David > > > > On Apr 12, 2022, at 11:29 AM, Swell <souheil.sul...@gmail.com> wrote: > > > > This reflects my first attempts, i still have them "per-version" > > uncommited, already linking to specs by precise version > > > > so it wont be too hard for me to turn around, and give you these > versions. > > > > the drawback is these pages may have to be maintained on dependencies > > updates and releases, but that may be ok and clearer for users visiting > the > > website. > > > > i'll send the per version to "tomee" repo first then the page for website > > repo > > > > On Tue, 12 Apr 2022 at 20:09, Zowalla, Richard < > > richard.zowa...@hs-heilbronn.de> wrote: > > > >> Makes sense, imho. Thanks for the thoughts, David. > >> That would simplify it for the reader. > >> > >> If we have it per version and link the per version documents from the > >> overall comparision, we are proabably in a good shape. > >> > >> > >> > >> Am Dienstag, dem 12.04.2022 um 10:58 -0700 schrieb David Blevins: > >>> Hey All, > >>> > >>> I see there's a big thread on PR#37. > >>> > >>> - https://github.com/apache/tomee-site-generator/pull/37 > >>> > >>> My gut reaction is that we might be trying to achieve the impossible > >>> by trying to fit every TomEE version and every Java EE/Jakarta EE > >>> version into one massive matrix or page. > >>> > >>> What do people think about potentially pausing that, taking a step > >>> back and seeing if there's a simpler approach. Often when I'm > >>> working on code and I notice it's getting just too big and hard to > >>> fit in my head or on the page in a way that makes sense, I change my > >>> approach. Instead of trying to solve the whole problem at once, I > >>> just take a slice of it that I know I'll need and work on it till > >>> it's clean. Then I move on and take another small slice and > >>> repeat. As I keep going I often find there is no more big mess, not > >>> because I found a better way to do it, but because I never needed it. > >>> > >>> My advice would be to give this a try. Pause the big PR#37 and shift > >>> gears. Instead try nailing just a basic comparison page for TomEE 9 > >>> that is like the one that's there, but adds the spec versions, links > >>> to the spec documents and the java information. > >>> > >>> I.e. we copy this page > >>> > >>> - > >>> > >> > https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/comparison.adoc > >>> > >>> To here: > >>> > >>> - > >>> https://github.com/apache/tomee/commits/master/docs/comparison.adoc > >>> > >>> Then we start with adding the spec versions and the spec links and > >>> get that merged. Afterwards we try adding the java information, and > >>> get that merged. Once we have a page we all like, we move on and do > >>> the same for TomEE 8.0 > >>> > >>> - > >>> https://github.com/apache/tomee/blob/tomee-8.x/docs/comparison.adoc > >>> > >>> If we have the energy, let's do 7.1 and 7.0 since we're still > >>> releasing those once in a while. > >>> > >>> Each page will be of course only mentioning the specifications they > >>> implement. We can even use the exact spec names as they existed, so > >>> for example, all the TomEE 7.0 stuff would say "Java EE" not "Jakarta > >>> EE" and use "Enterprise JavaBeans" not "Jakarta EnterpriseBeans", > >>> etc. > >>> > >>> Once we get individual pages for each TomEE version, we will likely > >>> have a different perspective on what we need for the main comparison > >>> page. Possibly we'll need very little as the individual pages will > >>> be doing most the hard work. > >>> > >>> > >>> Thoughts? > >>> > >>> > >>> -David > >>> > >>>> On Apr 5, 2022, at 5:42 AM, Swell <souheil.sul...@gmail.com> wrote: > >>>> > >>>> Thanks Richard, > >>>> > >>>> two pages can be pre-reviewed : > >>>> • compare-jakarta-versions.html > >>>> • comparison.html > >>>> i believe we can choose only one of the two for release. which one > >>>> do you find more readable ? > >>>> (they differ in the detailed list of jakarta specs.) > >>>> > >>>> i'll try to update my page later to better reflect JRE ranges and > >>>> your warnings on JRE/ASM. > >>>> i have reflected JL work regarding MicroProfile dependencies in my > >>>> draft PR. > >>>> > >>>> > >>>> also we could update TomEE 8.x to MicroProfile 4.1, > >>>> (SmallRye?) but is it worth ? > >>>> > >>>> Swell > >>>> > >>>> On Tue, 5 Apr 2022 at 11:49, Zowalla, Richard < > >>>> richard.zowa...@hs-heilbronn.de> wrote: > >>>> Hi Swell, > >>>> > >>>>> my TomEE 8.x is working on both JDK 11 and 17 with a small app. > >>>>> What > >>>> features can be broken with wrong JDK/ASM version ? > >>>> > >>>> (1) If you are running with an unsupported version of ASM the > >>>> server > >>>> might not startup or the deployment of applications will simply not > >>>> work. Most of often this will result in an exception (rather early) > >>>> telling you, that ASM does not support this specific version of > >>>> Java. > >>>> > >>>> (2) Our scripts are rather defensively written, but you might > >>>> encounter > >>>> issues with unsupported JVM flags (between major JDK versions) or > >>>> certain other mechanisms do not work (i.e. usages of Unsafe, > >>>> Illegal > >>>> Reflective Access, etc.) > >>>> > >>>> Most often this happens with "too new" JDKs (i.e. JDK 18-GA) as we > >>>> need > >>>> some time to adjust / test or wait for transient libs to be updated > >>>> (matter of resources). > >>>> > >>>>> TomEE works on both JDK and JRE, but can use more memory/cache in > >>>> JDK. is this right ? Is JDK to be preferred ? > >>>> > >>>> We are running TomEE with JRE (not JDK) in production and/or in > >>>> container environments (due to size). AFAIK our TomEE docker images > >>>> also rely on JRE (rather than JDK). > >>>> > >>>>> * TomEE implements MicroProfile 2.0 on branches 7.x, 8.x, 9.x ? > >>>>> or > >>>> other MP versions ? > >>>> > >>>> AFAIK we only support MP 2.x at the moment (in 7.x, 8.x and 9.x). > >>>> JL is > >>>> currently working on upgrading MP on 9.x with the smallray impl to > >>>> make > >>>> it work with the Jakarata namespace change. > >>>> > >>>> Hope it helps > >>>> Richard > >>>> > >>>> > >>>> Am Samstag, dem 02.04.2022 um 16:09 +0200 schrieb Swell: > >>>>> Thanks ! > >>>>> > >>>>> i've put some work for the website comparison pages on a draft > >>>>> PR > >>>>> https://github.com/apache/tomee-site-generator/pull/37 > >>>>> though I lack some info : > >>>>> > >>>>> * TomEE works on both JDK and JRE, but can use more memory/cache > >>>>> in > >>>>> JDK. is this right ? Is JDK to be preferred ? > >>>>> * my TomEE 8.x is working on both JDK 11 and 17 with a small app. > >>>>> What features can be broken with wrong JDK/ASM version ? > >>>>> * TomEE implements MicroProfile 2.0 on branches 7.x, 8.x, 9.x ? > >>>>> or > >>>>> other MP versions ? > >>>>> > >>>>> the pages i made are not perfect for maintenance, but i have > >>>>> ideas to > >>>>> improve them, > >>>>> for example : maybe not include the "spec versions" columns on my > >>>>> "per-tomee-major" pages. that would help avoid mistakes when > >>>>> realising a new major like 10, 11... > >>>>> > >>>>> maybe drop the per-major idea and keep only the main comparison > >>>>> page > >>>>> ? > >>>>> maybe keep the main comparison page but add a new one to display > >>>>> the > >>>>> complete mapping between TomEE versions and Specs versions ? > >>>>> > >>>>> i'am not ready to automate their generation, i did not see if the > >>>>> Jakarta Spec Process does release specs numbers in a format like > >>>>> JSON, > >>>>> that would be easier to parse than HTML > >>>>> https://projects.eclipse.org/releases/jakarta-10 > >>>>> the TomEE visitors could rely on these eclipse pages to identify > >>>>> the > >>>>> Jakarta version they need before choosing a TomEE version. > >>>>> > >>>>> the text i wrote is to be changed too. > >>>>> > >>>>> Open to your suggestions :-) > >>>>> Swell > >>>>> > >> > >
