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