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
