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 > > >
smime.p7s
Description: S/MIME cryptographic signature
