You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by "Zowalla, Richard" <ri...@hs-heilbronn.de> on 2022/04/01 06:48:11 UTC
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
I agree with both of you :)
It is a common question and is often asked on Stackoverflow: which
version of TomEE supports which JDK, which JEE Standard is covered with
which TomEE version, which TomEE version should be used in 2022, ...
I am sure we can be more clear on the website. I am happy to discuss /
give my thoughts on anything, you provide via a PR, Swell! :)
Every single contributions matters.
Gruß
Richard
Am Donnerstag, dem 31.03.2022 um 14:33 -0700 schrieb David Blevins:
> > On Mar 31, 2022, at 2:01 PM, Swell <so...@gmail.com>
> > wrote:
> >
> >
> > It would be great to have per-major comparison pages. And in fact,
> > there are, but their rendering are broken. i have some free time to
> > work on it. here are the existing urls I thought using
> >
> > https://tomee.apache.org/tomee-8.0/docs/comparison.html
> > https://tomee.apache.org/tomee-9.0/docs/comparison.html
>
> I totally forgot we had those pages and it looks like I'm the one who
> put them there (and left them broken for 3 years):
>
> -
> https://github.com/apache/tomee/commit/f779264f01c80e632649ff6dbe75f9b78bd359f0#diff-96bf7bb0a199a293ca950988b58249419c2a2cf667bf100750553c49671f9c63
>
> Getting those pages updated in at least the 8 and 9 branch would be
> great! Here's where they live:
>
> - https://github.com/apache/tomee/blob/master/docs/comparison.adoc
> -
> https://github.com/apache/tomee/blob/tomee-8.x/docs/comparison.adoc
>
> > listing the required Java and Jakarta specs version could be nice
> > too, i cant take ideas from
> > https://tomcat.apache.org/whichversion.html
>
> That's exactly the page I was thinking of :) We have so many specs,
> I think we'd want to keep our table the way it is now with the spec
> names going up and down on the left rather than across the top, but
> we can definitely add the spec versions like they have.
>
> An interesting aspect of the Java versions is Tomcat has "11 and
> later", where we don't really have that luxury. We use the ASM
> library to do a lot of work and that library will actual fail if you
> throw it a new Java version it wasn't explicitly written to
> handle. So for a long time we could support Java 8, but not Java 11
> for example. We only just added support for Java 17 in TomEE 8.0.8.
>
> I'm open to ideas on how we show that kind of thing. Maybe we need a
> table of the JDKs and "TomEE 8.0.8 and later" and similar written
> after each JDK version?
>
> > the main comparison page would have 2 synthesis table (flavors
> > comparison and versions comparison)
> > the per-major ones would have the detailed tables (specs, impls)
>
> Open to any thoughts. Feel free to hack something up.
>
> > I can put more thoughts on builds afterward :-)
>
> Sure! Welcome to the project btw! :)
>
>
> -David
>
> > On Thu, 31 Mar 2022 at 20:19, David Blevins <
> > david.blevins@gmail.com> wrote:
> > Thank you, Swell, for helping to get those versions aligned!
> >
> > Some high-level thoughts:
> >
> > - Romain is right that we could potentially use the TomEE-Maven-
> > Plugin to build the various distributions. Swell also had some
> > ideas on simplifying how the distributions are built. We've also
> > had a couple threads about completely eliminating the war file
> > distributions. Now that the master branch is TomEE 9.0 and that is
> > not final yet, do we want to take the time to work on this?
> >
> > - I've long thought it was odd our TomEE MicroProfile distribution
> > was larger than the TomEE WebProfile distribution. For TomEE 10,
> > which will need to have a Jakarta EE 10 Core Profile
> > implementation, perhaps we could strip down the TomEE MicroProfile
> > distribution so it doubles as Jakarta EE Core Profile /
> > MicroProfile? (again not really for TomEE 9, but soon).
> >
> > - Implementations are different for the various branches. In
> > TomEE 8 we're using Apache BVal, but for TomEE 9 we're using
> > Hibernate Bean Validator because it supports the jakarta namespace
> > and is compliant.
> >
> > - Comparison page. Given each version has differences in things
> > it implements and the implementations used, do we want a
> > specialized version of the comparison.html page that we put in each
> > branches documentation? Since it would be dedicated to a specific
> > TomEE version, we could not just list the specification names, but
> > also the specification versions and link to the actual
> > specifications themselves. Thinking there could be URLs like these
> >
> > - https://tomee.apache.org/tomee-8.0/comparison.html
> > - https://tomee.apache.org/tomee-9.0/comparison.html
> > - https://tomee.apache.org/tomee-10.0/comparison.html (future)
> >
> > We could potentially also list the Java version required.
> >
> > The generic comparison.html page at
> > https://tomee.apache.org/comparison.html could either stay as a
> > high-level view, or simply forward to the latest stable version
> > (which would be TomEE 8 at the moment). We could also take a
> > different direction with the generic
> > https://tomee.apache.org/comparison.html page and have it be kind
> > of a marketing page with fancy graphics to talk about each
> > distribution at a high level. Sort of like the "TomEE Flavors"
> > section of our website main page (https://tomee.apache.org) but a
> > more complete page where there is kind of an image and description
> > of each distribution. People can then use the more detailed
> > comparison pages for the full list of 40+ specifications we
> > support.
> >
> > Thoughts?
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> >
> > > On Mar 31, 2022, at 12:56 AM, Zowalla, Richard <
> > > richard.zowalla@hs-heilbronn.de> wrote:
> > >
> > > I went ahead and merged the changes by Swell. @Swell: Thank you!!
> > > Cherry picked them to master (9.x) as well.
> > >
> > > Now the distributions contain the libs specified on the website.
> > >
> > > Gruß
> > > Richard
> > >
> > > Am Montag, dem 28.03.2022 um 08:18 +0000 schrieb Zowalla,
> > > Richard:
> > > > As we merged the comparision page, we should now tackle:
> > > > https://github.com/apache/tomee/pull/828
> > > >
> > > > There was a discussion regarding the original intentions of
> > > > plume.
> > > > If we agree, that "Those distributions are supposed to be the
> > > > same
> > > > minus the JPA and JSF providers.", then we should go a-head and
> > > > merge
> > > > it + port it to master.
> > > >
> > > > Gruß
> > > > Richard
> > > >
> > > >
> > > > Am Freitag, dem 25.03.2022 um 11:29 +0100 schrieb Swell:
> > > > > Thanks for your kind feedback.
> > > > >
> > > > > @Richard, I'll gladly change Tomee Plume pom to include
> > > > > BatchEE, PR
> > > > > :
> > > > > in
> > > > > progress with a blocker i can also resolve.
> > > > >
> > > > > @David, about the flavors page, i think your suggestions are
> > > > > simpler
> > > > > and
> > > > > better, applied them on names consistency and added a table
> > > > > of
> > > > > implementations.
> > > > >
> > > > > what need for this list of implementations ?
> > > > > * For my students => My usual scenario is that i need to
> > > > > remind
> > > > > them
> > > > > of
> > > > > what is provided by Tomee vs other servers. "they dont need
> > > > > HK2 nor
> > > > > Jersey
> > > > > if they have the Plus flavor."
> > > > > * For the general web site visitors => I wonder if people
> > > > > would
> > > > > prefer perf
> > > > > metrics and tck results, rather than comparing what is
> > > > > provided by
> > > > > Tomee vs
> > > > > others. provided a web capture just for fun :
> > > > > https://issues.apache.org/jira/secure/attachment/13041580/image-2022-03-25-11-18-14-708.png
> > > > >
> > > > > i still believe the list of implementations is needed to know
> > > > > what
> > > > > Tomee
> > > > > provides, but David's suggestion is clearer.
> > > > > here is the current version of the web page in the PR :
> > > > > https://issues.apache.org/jira/secure/attachment/13041581/image-2022-03-25-11-19-03-406.png
> > > > >
> > > > > On Fri, 25 Mar 2022 at 06:18, Zowalla, Richard <
> > > > > richard.zowalla@hs-heilbronn.de> wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Thanks for your mail and your work in making the page more
> > > > > > clear,
> > > > > > Swell! Your work is very much appreciated.
> > > > > >
> > > > > >
> > > > > > > Total side note to the wider dev list, we really need to
> > > > > > > get
> > > > > > > JBatch
> > > > > > > into Plume! Those distributions are supposed to be the
> > > > > > > same
> > > > > > > minus
> > > > > > > the JPA and JSF providers.
> > > > > >
> > > > > > I created TOMEE-3871 [1] for this one.
> > > > > >
> > > > > > @Swell Let me know, if you like to provide a PR for master
> > > > > > /
> > > > > > tomee-
> > > > > > 8.x
> > > > > > branch to fix it. We can then assign you the Jira :)
> > > > > >
> > > > > > It basically boils down to adding "batchee-jbatch"
> > > > > > (runtime) to
> > > > > > the
> > > > > > "tomee-plume-webapp". The references in the "boms" are then
> > > > > > automatically re-generated, if you conduct a quick build:
> > > > > >
> > > > > > mvn -U -Pquick -DskipTests -Dsurefire.useFile=false
> > > > > > -DdisableXmlReport=true -DuniqueVersion=false -ff
> > > > > > -Dassemble
> > > > > > -DfailIfNoTests=false clean install
> > > > > >
> > > > > > If you are unsure how to proceed with it, feel free to ask.
> > > > > > We
> > > > > > are
> > > > > > happy to help.
> > > > > >
> > > > > > Gruß
> > > > > > Richard
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/TOMEE-3871
> > > > > >
> > > > > > Am Donnerstag, dem 24.03.2022 um 11:48 -0700 schrieb David
> > > > > > Blevins:
> > > > > > > > On Mar 19, 2022, at 2:30 AM, Swell <
> > > > > > > > souheil.sultan@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > Regarding Tomee website : one web page mislead me to
> > > > > > > > believe
> > > > > > > > that
> > > > > > > > Tomee Plus
> > > > > > > > includes Tomee Plume, and it made it hard for me to
> > > > > > > > understand
> > > > > > > > why
> > > > > > > > my
> > > > > > > > webapp was not loading.
> > > > > > > >
> > > > > > > > I believe it could mislead others and its why I wanted
> > > > > > > > to
> > > > > > > > suggest
> > > > > > > > some
> > > > > > > > changes on its content to better show the delta between
> > > > > > > > flavors.
> > > > > > > >
> > > > > > > > Currently the flavors page does not differentiate
> > > > > > > > between
> > > > > > > > Micro
> > > > > > > > and
> > > > > > > > Web
> > > > > > > > profiles, nor does it tell Plume includes EclipseLink
> > > > > > > > when
> > > > > > > > Plus
> > > > > > > > does not.
> > > > > > > >
> > > > > > > > I took time to write a page I believe could be usefull
> > > > > > > > to
> > > > > > > > Tomee
> > > > > > > > users, a
> > > > > > > > screenshot is linked below, the visitors could benefit
> > > > > > > > from
> > > > > > > > my
> > > > > > > > additional
> > > > > > > > table for synthesis of deltas.
> > > > > > > >
> > > > > > > >
> > > > > > https://issues.apache.org/jira/secure/attachment/13041318/image-2022-03-18-20-36-25-938.png
> > > > > > > Hi Swell,
> > > > > > >
> > > > > > > Thank you so much for taking the time to put so much
> > > > > > > thought
> > > > > > > into
> > > > > > > this work. We are truly lucky :)
> > > > > > >
> > > > > > > I love that you included the MicroProfile detail, that
> > > > > > > was
> > > > > > > definitely
> > > > > > > missing and badly needed. As the table is quite large
> > > > > > > already,
> > > > > > > that
> > > > > > > terse summary at the top is a very nice improvement and
> > > > > > > likely
> > > > > > > to
> > > > > > > help people see the big picture significantly faster.
> > > > > > >
> > > > > > > In the first table, I like the way you used "Jakarta JSF
> > > > > > > Implementation" and list the implementations by
> > > > > > > name. For
> > > > > > > consistency, can we use that same approach for the line
> > > > > > > above? Instead of it saying "EclipseLink" and having a
> > > > > > > checkmark,
> > > > > > > could we also have it say "Jakarta Persistence (JPA)
> > > > > > > Implementation"
> > > > > > > and then put "OpenJPA, OpenJPA, EcliseLink, OpenJPA" in
> > > > > > > there? We
> > > > > > > can do that in both the top and bottom tables.
> > > > > > >
> > > > > > > On listing OpenEJB in the bottom table. I think it's
> > > > > > > fine I'm
> > > > > > > not
> > > > > > > the best judge of what people think is useful information
> > > > > > > as
> > > > > > > I've
> > > > > > > been working on the project too long and everything is
> > > > > > > "obvious." Do
> > > > > > > you find it helpful to see OpenEJB listed even though
> > > > > > > it's the
> > > > > > > same
> > > > > > > for all distributions. Do you think we possibly need a
> > > > > > > table
> > > > > > > entirely dedicated to implementations? (OpenWebBeans,
> > > > > > > Geronimo
> > > > > > > Transaction Manager, BVal, etc)
> > > > > > >
> > > > > > > Some minor trademark corrections:
> > > > > > >
> > > > > > > - "GlassFish Mojarra" is "Eclipse Mojarra"
> > > > > > > - "Jakarta JSF" is "Jakarta Faces", but "Jakarta Faces
> > > > > > > (JSF)"
> > > > > > > is
> > > > > > > completely fine and encouraged so people are aware of its
> > > > > > > new
> > > > > > > and
> > > > > > > former name.
> > > > > > > - "Jakarta EJB" is "Jakarta Enterprise Beans", but
> > > > > > > "Jakarta
> > > > > > > Enterprise Beans (EJB)" is completely fine and encouraged
> > > > > > > so
> > > > > > > people
> > > > > > > are aware of its new and former name.
> > > > > > > - "Jakarta JPA" is "Jakarta Persistence", but "Jakarta
> > > > > > > Persistence
> > > > > > > (JPA)" is completely fine and encouraged so people are
> > > > > > > aware of
> > > > > > > its
> > > > > > > new and former name.
> > > > > > > - OpenJPA, OpenEJB and MyFaces are all Apache trademarks,
> > > > > > > so
> > > > > > > if
> > > > > > > we're going to say "Apache MyFaces" on the page, we need
> > > > > > > to
> > > > > > > also
> > > > > > > use
> > > > > > > "Apache OpenJPA" and "Apache OpenEJB"
> > > > > > >
> > > > > > >
> > > > > > > Total side note to the wider dev list, we really need to
> > > > > > > get
> > > > > > > JBatch
> > > > > > > into Plume! Those distributions are supposed to be the
> > > > > > > same
> > > > > > > minus
> > > > > > > the JPA and JSF providers.
> > > > > > >
> > > > > > >
> > > > > > > Thank you so much, again, for all work on this and being
> > > > > > > patient
> > > > > > > getting bounced around between different repos and
> > > > > > > ultimately
> > > > > > > onto
> > > > > > > the list. We'd be happy to see you post as often as you
> > > > > > > like
> > > > > > > :)
> > > > > > >
> > > > > > >
> > > > > > > -David
> > > > > > >
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by Cesar Hernandez <ce...@gmail.com>.
>
> all the TomEE 7.0 stuff would say "Java EE" not "Jakarta EE" and use
> "Enterprise JavaBeans" not "Jakarta EnterpriseBeans", etc.
Agree, I overlooked the fact that spec names changed along with namespace.
El mar, 12 abr 2022 a las 12:09, Zowalla, Richard (<
richard.zowalla@hs-heilbronn.de>) escribió:
> 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 <so...@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.zowalla@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
> > > >
>
--
Atentamente:
César Hernández.
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by Swell <so...@gmail.com>.
Feedbacks taken to improve pages on 4 branches (7.0, 7.1, 8, 9)
pending questions should be in
https://github.com/apache/tomee/pull/866#issuecomment-1103873430
- Swell
On Wed, 20 Apr 2022 at 20:46, Swell <so...@gmail.com> wrote:
> Thanks!
>
> * i took the Java EE 7 pdf spec to get JSR ids
> * i added comparison page for 7.0 without MP
> * currently taking the github feedback into the pages
>
> Swell
>
> On Wed, 20 Apr 2022 at 20:25, David Blevins <da...@gmail.com>
> wrote:
>
>> > On Apr 20, 2022, at 11:13 AM, David Blevins <da...@gmail.com>
>> wrote:
>> >
>> >> - i lack some JSR specs number, i need to dig them, working on it,
>> help
>> >> appreciated
>>
>> On this one, I don't have the JSR numbers handy but TomEE 7 is based on
>> Java EE 7. If you grab the Java EE 7 spec, the right JSRs numbers are
>> scattered around:
>>
>> -
>> https://download.oracle.com/otndocs/jcp/java_ee-7-mrel-eval-spec/index.html
>>
>>
>> -David
>>
>>
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by Swell <so...@gmail.com>.
Thanks!
* i took the Java EE 7 pdf spec to get JSR ids
* i added comparison page for 7.0 without MP
* currently taking the github feedback into the pages
Swell
On Wed, 20 Apr 2022 at 20:25, David Blevins <da...@gmail.com> wrote:
> > On Apr 20, 2022, at 11:13 AM, David Blevins <da...@gmail.com>
> wrote:
> >
> >> - i lack some JSR specs number, i need to dig them, working on it, help
> >> appreciated
>
> On this one, I don't have the JSR numbers handy but TomEE 7 is based on
> Java EE 7. If you grab the Java EE 7 spec, the right JSRs numbers are
> scattered around:
>
> -
> https://download.oracle.com/otndocs/jcp/java_ee-7-mrel-eval-spec/index.html
>
>
> -David
>
>
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by David Blevins <da...@gmail.com>.
> On Apr 20, 2022, at 11:13 AM, David Blevins <da...@gmail.com> wrote:
>
>> - i lack some JSR specs number, i need to dig them, working on it, help
>> appreciated
On this one, I don't have the JSR numbers handy but TomEE 7 is based on Java EE 7. If you grab the Java EE 7 spec, the right JSRs numbers are scattered around:
- https://download.oracle.com/otndocs/jcp/java_ee-7-mrel-eval-spec/index.html
-David
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by David Blevins <da...@gmail.com>.
> On Apr 20, 2022, at 3:59 AM, Swell <so...@gmail.com> wrote:
>
> i also agree about ease of maintenance.
>
> i started working on comparison page v7.1, here are some thoughts :
> https://github.com/apache/tomee/pull/866
>
> i have several questions/issues:
>
> - i lack some JSR specs number, i need to dig them, working on it, help
> appreciated
> - this comparison page would be a quasi duplicate between 7.0 and 7.1,
> it is ok for now.
> - there are 2 TomEE minors (v7.0,v7.1) for 1 Java EE (v7) its ok if
> it stays like that.
> it may be a pain later if there is again 2 TomEE for 1 Jakarta (say
> TomEE v10.0 and TomEE v10.1 for same Jakarta 10.0).
> could this happen again ?
> - i would appreciate feedbacks on this suggested comparison page
> - is red cross a bad idea to tell EE7 does not include JSON-B ?
> do i better remove the lines with red crosses (specs not part of EE7)
> ?
>
> instead of making a comparison page for every TomEE minors (7.0, 7.1, 8, 9),
> could i make a comparison page for every Java/Jakarta minors (7, 8, 9.1,
> 10.0) ?
> (and put them on the main website instead)
>
> i'm not sure whats the best option.
>
> here is what i'am working on :
>
> - tomee.apache.org/
> - comparison.html
> - tomee-7.1/docs/comparison.html (more risk ok duplicate)
> - tomee-8.0/docs/comparison.html
> - tomee-9.0/docs/comparison.html
We can certainly add other comparisons, but we definitely want to keep a comparison page that answers the question of how the different TomEE distributions compare to each other and Tomcat for that particular release.
Comparing different TomEE versions to each other or comparing different Jakarta EE versions to other Jakarta EE versions can be useful, but doesn't eliminate the need for a dedicated page that helps people answer the question "Which distribution of TomEE 8 should I download?"
On the minor versions. We don't do those often. When we do do them it's because we've changed something fundamental about the server. For example we created TomEE 7.1 because we wanted to add MicroProfile implementations, but did not feel good about doing that in a patch release on 7.0.x. So in reality the 7.0 and 7.1 comparison pages are going to be quite different. The 7.0 page will have no TomEE MicroProfile distribution and no MicroProfile specs. The TomEE 7.1 will have the new TomEE MicroProfile distribution and some MicroProfile specs.
What I can't remember is when we added MicroProfile specs to TomEE Plus and Plume. I know initially those two distributions did not contain any MicroProfile support, but I can't remember if we eventually added that before 7.1 went final or if we did that in TomEE 8.0. A page per release will really help us all keep stuff like that straight.
-David
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by Swell <so...@gmail.com>.
i also agree about ease of maintenance.
i started working on comparison page v7.1, here are some thoughts :
https://github.com/apache/tomee/pull/866
i have several questions/issues:
- i lack some JSR specs number, i need to dig them, working on it, help
appreciated
- this comparison page would be a quasi duplicate between 7.0 and 7.1,
it is ok for now.
- there are 2 TomEE minors (v7.0,v7.1) for 1 Java EE (v7) its ok if
it stays like that.
it may be a pain later if there is again 2 TomEE for 1 Jakarta (say
TomEE v10.0 and TomEE v10.1 for same Jakarta 10.0).
could this happen again ?
- i would appreciate feedbacks on this suggested comparison page
- is red cross a bad idea to tell EE7 does not include JSON-B ?
do i better remove the lines with red crosses (specs not part of EE7)
?
instead of making a comparison page for every TomEE minors (7.0, 7.1, 8, 9),
could i make a comparison page for every Java/Jakarta minors (7, 8, 9.1,
10.0) ?
(and put them on the main website instead)
i'm not sure whats the best option.
here is what i'am working on :
- tomee.apache.org/
- comparison.html
- tomee-7.1/docs/comparison.html (more risk ok duplicate)
- tomee-8.0/docs/comparison.html
- tomee-9.0/docs/comparison.html
here is an alternative :
- tomee.apache.org/
- comparison.html
- comparison-jakartaee-7.html (no risk ok duplicate)
- comparison-jakartaee-8.html
- comparison-jakartaee-9.html
- comparison-jakartaee-10.html
We all have a lot of work this week, so no worries about the time we need
to make this good,
i'll keep my coding train on the tracks we agreed on for the moment
Swell
On Wed, 20 Apr 2022 at 08:14, Zowalla, Richard <
richard.zowalla@hs-heilbronn.de> wrote:
> Comments are still pending? Didn't see any?
>
> +1 for don't maintain it in two different places + David's idea.
>
> Gruß
> Richard
>
> Am Dienstag, dem 19.04.2022 um 14:33 -0700 schrieb David Blevins:
> > Those pages looking great! Left some specific comments in the PR.
> >
> > > On Apr 17, 2022, at 12:10 PM, Swell <so...@gmail.com>
> > > wrote:
> > >
> > > 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
> >
> > Thanks for tracking down all that version information! That's always
> > a lot of tedious digging.
> >
> > > 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:
> >
> > I agree we definitely don't want it in two places. In my experience
> > documentation doesn't get maintained well, so anything duplicated
> > usually ends up drifting apart and causing confusion.
> >
> > My vote would be to kill the implementation information from the main
> > comparison and leave that information only in the comparison pages
> > dedicated to their specific version.
> >
> >
> > -David
> >
> >
> > > On Tue, 12 Apr 2022 at 21:04, David Blevins <
> > > david.blevins@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 <so...@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.zowalla@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.sultan@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.zowalla@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
> > > > > > > > >
>
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Comments are still pending? Didn't see any?
+1 for don't maintain it in two different places + David's idea.
Gruß
Richard
Am Dienstag, dem 19.04.2022 um 14:33 -0700 schrieb David Blevins:
> Those pages looking great! Left some specific comments in the PR.
>
> > On Apr 17, 2022, at 12:10 PM, Swell <so...@gmail.com>
> > wrote:
> >
> > 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
>
> Thanks for tracking down all that version information! That's always
> a lot of tedious digging.
>
> > 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:
>
> I agree we definitely don't want it in two places. In my experience
> documentation doesn't get maintained well, so anything duplicated
> usually ends up drifting apart and causing confusion.
>
> My vote would be to kill the implementation information from the main
> comparison and leave that information only in the comparison pages
> dedicated to their specific version.
>
>
> -David
>
>
> > On Tue, 12 Apr 2022 at 21:04, David Blevins <
> > david.blevins@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 <so...@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.zowalla@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.sultan@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.zowalla@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
> > > > > > > >
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by David Blevins <da...@gmail.com>.
Those pages looking great! Left some specific comments in the PR.
> On Apr 17, 2022, at 12:10 PM, Swell <so...@gmail.com> wrote:
>
> 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
Thanks for tracking down all that version information! That's always a lot of tedious digging.
> 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:
I agree we definitely don't want it in two places. In my experience documentation doesn't get maintained well, so anything duplicated usually ends up drifting apart and causing confusion.
My vote would be to kill the implementation information from the main comparison and leave that information only in the comparison pages dedicated to their specific version.
-David
>
> On Tue, 12 Apr 2022 at 21:04, David Blevins <da...@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 <so...@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.zowalla@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 <so...@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.zowalla@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
>>>>>>>
>>>>
>>
>>
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by Swell <so...@gmail.com>.
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 <da...@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 <so...@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.zowalla@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 <so...@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.zowalla@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
> >>>>>
> >>
>
>
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by David Blevins <da...@gmail.com>.
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 <so...@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.zowalla@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 <so...@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.zowalla@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
>>>>>
>>
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by Swell <so...@gmail.com>.
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.zowalla@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 <so...@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.zowalla@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
> > > >
>
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
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 <so...@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.zowalla@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
> > >
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by David Blevins <da...@gmail.com>.
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 <so...@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 <ri...@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
> >
Fwd: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by Swell <so...@gmail.com>.
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.
[image: image.png][image: image.png]
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.zowalla@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
> >
>
Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache
Posted by Swell <so...@gmail.com>.
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
On Fri, 1 Apr 2022 at 08:48, Zowalla, Richard <
richard.zowalla@hs-heilbronn.de> wrote:
> I agree with both of you :)
>
> It is a common question and is often asked on Stackoverflow: which
> version of TomEE supports which JDK, which JEE Standard is covered with
> which TomEE version, which TomEE version should be used in 2022, ...
>
> I am sure we can be more clear on the website. I am happy to discuss /
> give my thoughts on anything, you provide via a PR, Swell! :)
>
> Every single contributions matters.
>
> Gruß
> Richard
>
>
> Am Donnerstag, dem 31.03.2022 um 14:33 -0700 schrieb David Blevins:
> > > On Mar 31, 2022, at 2:01 PM, Swell <so...@gmail.com>
> > > wrote:
> > >
> > >
> > > It would be great to have per-major comparison pages. And in fact,
> > > there are, but their rendering are broken. i have some free time to
> > > work on it. here are the existing urls I thought using
> > >
> > > https://tomee.apache.org/tomee-8.0/docs/comparison.html
> > > https://tomee.apache.org/tomee-9.0/docs/comparison.html
> >
> > I totally forgot we had those pages and it looks like I'm the one who
> > put them there (and left them broken for 3 years):
> >
> > -
> >
> https://github.com/apache/tomee/commit/f779264f01c80e632649ff6dbe75f9b78bd359f0#diff-96bf7bb0a199a293ca950988b58249419c2a2cf667bf100750553c49671f9c63
> >
> > Getting those pages updated in at least the 8 and 9 branch would be
> > great! Here's where they live:
> >
> > - https://github.com/apache/tomee/blob/master/docs/comparison.adoc
> > -
> > https://github.com/apache/tomee/blob/tomee-8.x/docs/comparison.adoc
> >
> > > listing the required Java and Jakarta specs version could be nice
> > > too, i cant take ideas from
> > > https://tomcat.apache.org/whichversion.html
> >
> > That's exactly the page I was thinking of :) We have so many specs,
> > I think we'd want to keep our table the way it is now with the spec
> > names going up and down on the left rather than across the top, but
> > we can definitely add the spec versions like they have.
> >
> > An interesting aspect of the Java versions is Tomcat has "11 and
> > later", where we don't really have that luxury. We use the ASM
> > library to do a lot of work and that library will actual fail if you
> > throw it a new Java version it wasn't explicitly written to
> > handle. So for a long time we could support Java 8, but not Java 11
> > for example. We only just added support for Java 17 in TomEE 8.0.8.
> >
> > I'm open to ideas on how we show that kind of thing. Maybe we need a
> > table of the JDKs and "TomEE 8.0.8 and later" and similar written
> > after each JDK version?
> >
> > > the main comparison page would have 2 synthesis table (flavors
> > > comparison and versions comparison)
> > > the per-major ones would have the detailed tables (specs, impls)
> >
> > Open to any thoughts. Feel free to hack something up.
> >
> > > I can put more thoughts on builds afterward :-)
> >
> > Sure! Welcome to the project btw! :)
> >
> >
> > -David
> >
> > > On Thu, 31 Mar 2022 at 20:19, David Blevins <
> > > david.blevins@gmail.com> wrote:
> > > Thank you, Swell, for helping to get those versions aligned!
> > >
> > > Some high-level thoughts:
> > >
> > > - Romain is right that we could potentially use the TomEE-Maven-
> > > Plugin to build the various distributions. Swell also had some
> > > ideas on simplifying how the distributions are built. We've also
> > > had a couple threads about completely eliminating the war file
> > > distributions. Now that the master branch is TomEE 9.0 and that is
> > > not final yet, do we want to take the time to work on this?
> > >
> > > - I've long thought it was odd our TomEE MicroProfile distribution
> > > was larger than the TomEE WebProfile distribution. For TomEE 10,
> > > which will need to have a Jakarta EE 10 Core Profile
> > > implementation, perhaps we could strip down the TomEE MicroProfile
> > > distribution so it doubles as Jakarta EE Core Profile /
> > > MicroProfile? (again not really for TomEE 9, but soon).
> > >
> > > - Implementations are different for the various branches. In
> > > TomEE 8 we're using Apache BVal, but for TomEE 9 we're using
> > > Hibernate Bean Validator because it supports the jakarta namespace
> > > and is compliant.
> > >
> > > - Comparison page. Given each version has differences in things
> > > it implements and the implementations used, do we want a
> > > specialized version of the comparison.html page that we put in each
> > > branches documentation? Since it would be dedicated to a specific
> > > TomEE version, we could not just list the specification names, but
> > > also the specification versions and link to the actual
> > > specifications themselves. Thinking there could be URLs like these
> > >
> > > - https://tomee.apache.org/tomee-8.0/comparison.html
> > > - https://tomee.apache.org/tomee-9.0/comparison.html
> > > - https://tomee.apache.org/tomee-10.0/comparison.html (future)
> > >
> > > We could potentially also list the Java version required.
> > >
> > > The generic comparison.html page at
> > > https://tomee.apache.org/comparison.html could either stay as a
> > > high-level view, or simply forward to the latest stable version
> > > (which would be TomEE 8 at the moment). We could also take a
> > > different direction with the generic
> > > https://tomee.apache.org/comparison.html page and have it be kind
> > > of a marketing page with fancy graphics to talk about each
> > > distribution at a high level. Sort of like the "TomEE Flavors"
> > > section of our website main page (https://tomee.apache.org) but a
> > > more complete page where there is kind of an image and description
> > > of each distribution. People can then use the more detailed
> > > comparison pages for the full list of 40+ specifications we
> > > support.
> > >
> > > Thoughts?
> > >
> > >
> > > --
> > > David Blevins
> > > http://twitter.com/dblevins
> > > http://www.tomitribe.com
> > >
> > > > On Mar 31, 2022, at 12:56 AM, Zowalla, Richard <
> > > > richard.zowalla@hs-heilbronn.de> wrote:
> > > >
> > > > I went ahead and merged the changes by Swell. @Swell: Thank you!!
> > > > Cherry picked them to master (9.x) as well.
> > > >
> > > > Now the distributions contain the libs specified on the website.
> > > >
> > > > Gruß
> > > > Richard
> > > >
> > > > Am Montag, dem 28.03.2022 um 08:18 +0000 schrieb Zowalla,
> > > > Richard:
> > > > > As we merged the comparision page, we should now tackle:
> > > > > https://github.com/apache/tomee/pull/828
> > > > >
> > > > > There was a discussion regarding the original intentions of
> > > > > plume.
> > > > > If we agree, that "Those distributions are supposed to be the
> > > > > same
> > > > > minus the JPA and JSF providers.", then we should go a-head and
> > > > > merge
> > > > > it + port it to master.
> > > > >
> > > > > Gruß
> > > > > Richard
> > > > >
> > > > >
> > > > > Am Freitag, dem 25.03.2022 um 11:29 +0100 schrieb Swell:
> > > > > > Thanks for your kind feedback.
> > > > > >
> > > > > > @Richard, I'll gladly change Tomee Plume pom to include
> > > > > > BatchEE, PR
> > > > > > :
> > > > > > in
> > > > > > progress with a blocker i can also resolve.
> > > > > >
> > > > > > @David, about the flavors page, i think your suggestions are
> > > > > > simpler
> > > > > > and
> > > > > > better, applied them on names consistency and added a table
> > > > > > of
> > > > > > implementations.
> > > > > >
> > > > > > what need for this list of implementations ?
> > > > > > * For my students => My usual scenario is that i need to
> > > > > > remind
> > > > > > them
> > > > > > of
> > > > > > what is provided by Tomee vs other servers. "they dont need
> > > > > > HK2 nor
> > > > > > Jersey
> > > > > > if they have the Plus flavor."
> > > > > > * For the general web site visitors => I wonder if people
> > > > > > would
> > > > > > prefer perf
> > > > > > metrics and tck results, rather than comparing what is
> > > > > > provided by
> > > > > > Tomee vs
> > > > > > others. provided a web capture just for fun :
> > > > > >
> https://issues.apache.org/jira/secure/attachment/13041580/image-2022-03-25-11-18-14-708.png
> > > > > >
> > > > > > i still believe the list of implementations is needed to know
> > > > > > what
> > > > > > Tomee
> > > > > > provides, but David's suggestion is clearer.
> > > > > > here is the current version of the web page in the PR :
> > > > > >
> https://issues.apache.org/jira/secure/attachment/13041581/image-2022-03-25-11-19-03-406.png
> > > > > >
> > > > > > On Fri, 25 Mar 2022 at 06:18, Zowalla, Richard <
> > > > > > richard.zowalla@hs-heilbronn.de> wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Thanks for your mail and your work in making the page more
> > > > > > > clear,
> > > > > > > Swell! Your work is very much appreciated.
> > > > > > >
> > > > > > >
> > > > > > > > Total side note to the wider dev list, we really need to
> > > > > > > > get
> > > > > > > > JBatch
> > > > > > > > into Plume! Those distributions are supposed to be the
> > > > > > > > same
> > > > > > > > minus
> > > > > > > > the JPA and JSF providers.
> > > > > > >
> > > > > > > I created TOMEE-3871 [1] for this one.
> > > > > > >
> > > > > > > @Swell Let me know, if you like to provide a PR for master
> > > > > > > /
> > > > > > > tomee-
> > > > > > > 8.x
> > > > > > > branch to fix it. We can then assign you the Jira :)
> > > > > > >
> > > > > > > It basically boils down to adding "batchee-jbatch"
> > > > > > > (runtime) to
> > > > > > > the
> > > > > > > "tomee-plume-webapp". The references in the "boms" are then
> > > > > > > automatically re-generated, if you conduct a quick build:
> > > > > > >
> > > > > > > mvn -U -Pquick -DskipTests -Dsurefire.useFile=false
> > > > > > > -DdisableXmlReport=true -DuniqueVersion=false -ff
> > > > > > > -Dassemble
> > > > > > > -DfailIfNoTests=false clean install
> > > > > > >
> > > > > > > If you are unsure how to proceed with it, feel free to ask.
> > > > > > > We
> > > > > > > are
> > > > > > > happy to help.
> > > > > > >
> > > > > > > Gruß
> > > > > > > Richard
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/TOMEE-3871
> > > > > > >
> > > > > > > Am Donnerstag, dem 24.03.2022 um 11:48 -0700 schrieb David
> > > > > > > Blevins:
> > > > > > > > > On Mar 19, 2022, at 2:30 AM, Swell <
> > > > > > > > > souheil.sultan@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Regarding Tomee website : one web page mislead me to
> > > > > > > > > believe
> > > > > > > > > that
> > > > > > > > > Tomee Plus
> > > > > > > > > includes Tomee Plume, and it made it hard for me to
> > > > > > > > > understand
> > > > > > > > > why
> > > > > > > > > my
> > > > > > > > > webapp was not loading.
> > > > > > > > >
> > > > > > > > > I believe it could mislead others and its why I wanted
> > > > > > > > > to
> > > > > > > > > suggest
> > > > > > > > > some
> > > > > > > > > changes on its content to better show the delta between
> > > > > > > > > flavors.
> > > > > > > > >
> > > > > > > > > Currently the flavors page does not differentiate
> > > > > > > > > between
> > > > > > > > > Micro
> > > > > > > > > and
> > > > > > > > > Web
> > > > > > > > > profiles, nor does it tell Plume includes EclipseLink
> > > > > > > > > when
> > > > > > > > > Plus
> > > > > > > > > does not.
> > > > > > > > >
> > > > > > > > > I took time to write a page I believe could be usefull
> > > > > > > > > to
> > > > > > > > > Tomee
> > > > > > > > > users, a
> > > > > > > > > screenshot is linked below, the visitors could benefit
> > > > > > > > > from
> > > > > > > > > my
> > > > > > > > > additional
> > > > > > > > > table for synthesis of deltas.
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> https://issues.apache.org/jira/secure/attachment/13041318/image-2022-03-18-20-36-25-938.png
> > > > > > > > Hi Swell,
> > > > > > > >
> > > > > > > > Thank you so much for taking the time to put so much
> > > > > > > > thought
> > > > > > > > into
> > > > > > > > this work. We are truly lucky :)
> > > > > > > >
> > > > > > > > I love that you included the MicroProfile detail, that
> > > > > > > > was
> > > > > > > > definitely
> > > > > > > > missing and badly needed. As the table is quite large
> > > > > > > > already,
> > > > > > > > that
> > > > > > > > terse summary at the top is a very nice improvement and
> > > > > > > > likely
> > > > > > > > to
> > > > > > > > help people see the big picture significantly faster.
> > > > > > > >
> > > > > > > > In the first table, I like the way you used "Jakarta JSF
> > > > > > > > Implementation" and list the implementations by
> > > > > > > > name. For
> > > > > > > > consistency, can we use that same approach for the line
> > > > > > > > above? Instead of it saying "EclipseLink" and having a
> > > > > > > > checkmark,
> > > > > > > > could we also have it say "Jakarta Persistence (JPA)
> > > > > > > > Implementation"
> > > > > > > > and then put "OpenJPA, OpenJPA, EcliseLink, OpenJPA" in
> > > > > > > > there? We
> > > > > > > > can do that in both the top and bottom tables.
> > > > > > > >
> > > > > > > > On listing OpenEJB in the bottom table. I think it's
> > > > > > > > fine I'm
> > > > > > > > not
> > > > > > > > the best judge of what people think is useful information
> > > > > > > > as
> > > > > > > > I've
> > > > > > > > been working on the project too long and everything is
> > > > > > > > "obvious." Do
> > > > > > > > you find it helpful to see OpenEJB listed even though
> > > > > > > > it's the
> > > > > > > > same
> > > > > > > > for all distributions. Do you think we possibly need a
> > > > > > > > table
> > > > > > > > entirely dedicated to implementations? (OpenWebBeans,
> > > > > > > > Geronimo
> > > > > > > > Transaction Manager, BVal, etc)
> > > > > > > >
> > > > > > > > Some minor trademark corrections:
> > > > > > > >
> > > > > > > > - "GlassFish Mojarra" is "Eclipse Mojarra"
> > > > > > > > - "Jakarta JSF" is "Jakarta Faces", but "Jakarta Faces
> > > > > > > > (JSF)"
> > > > > > > > is
> > > > > > > > completely fine and encouraged so people are aware of its
> > > > > > > > new
> > > > > > > > and
> > > > > > > > former name.
> > > > > > > > - "Jakarta EJB" is "Jakarta Enterprise Beans", but
> > > > > > > > "Jakarta
> > > > > > > > Enterprise Beans (EJB)" is completely fine and encouraged
> > > > > > > > so
> > > > > > > > people
> > > > > > > > are aware of its new and former name.
> > > > > > > > - "Jakarta JPA" is "Jakarta Persistence", but "Jakarta
> > > > > > > > Persistence
> > > > > > > > (JPA)" is completely fine and encouraged so people are
> > > > > > > > aware of
> > > > > > > > its
> > > > > > > > new and former name.
> > > > > > > > - OpenJPA, OpenEJB and MyFaces are all Apache trademarks,
> > > > > > > > so
> > > > > > > > if
> > > > > > > > we're going to say "Apache MyFaces" on the page, we need
> > > > > > > > to
> > > > > > > > also
> > > > > > > > use
> > > > > > > > "Apache OpenJPA" and "Apache OpenEJB"
> > > > > > > >
> > > > > > > >
> > > > > > > > Total side note to the wider dev list, we really need to
> > > > > > > > get
> > > > > > > > JBatch
> > > > > > > > into Plume! Those distributions are supposed to be the
> > > > > > > > same
> > > > > > > > minus
> > > > > > > > the JPA and JSF providers.
> > > > > > > >
> > > > > > > >
> > > > > > > > Thank you so much, again, for all work on this and being
> > > > > > > > patient
> > > > > > > > getting bounced around between different repos and
> > > > > > > > ultimately
> > > > > > > > onto
> > > > > > > > the list. We'd be happy to see you post as often as you
> > > > > > > > like
> > > > > > > > :)
> > > > > > > >
> > > > > > > >
> > > > > > > > -David
> > > > > > > >
>