[GitHub] [tomee] rzo1 merged pull request #833: Regenerated BOMs after dependency upgrades

[GitBox]

rzo1 merged pull request #833:
URL: https://github.com/apache/tomee/pull/833


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [tomee] github-actions[bot] opened a new pull request #833: Regenerated BOMs after dependency upgrades

[GitBox]

github-actions[bot] opened a new pull request #833:
URL: https://github.com/apache/tomee/pull/833


   Found some uncommited changes (from BOM regeneration) after running build on 
TomEE master


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: TomEE MicroProfile and Jakarta

[David Blevins]

This is very close.  The dangers of A are not quite captured.  Completely agree 
with the dangers of B.

> On Apr 1, 2022, at 1:13 AM, Zowalla, Richard 
>  wrote:
> 
> So we basically have to options (if I understand the discussion
> correctly):
> 
> (A) Put some effort / resources into upgrade our MP impls to the latest
> versions to fully support Jakarta namespace. From my understanding
> maintaining these impls is a bit PITA as MP tends to break its API
> every few months, right? It will take some time, effort and resources
> to catch up.

The danger here is that we - due to lack of time / resources - will continue to 
not be seen as a viable MicroProfile implementation.

MicroProfile is approximately 70 months old.  We were able to keep up for only 
1.5 months out of that 70.  It was with TomEE 7.1, released with MicroProfile 
2.0 support in September of 2018, outdated by MicroProfile 2.1 in October 2018. 
 We were 27 months late to getting our first and only MicroProfile version 
implemented, which is now 41 months out of date.

> 
> (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
> side, which breaks the "we use apache impls"-credo but enables a faster
> move forward. I see the danger here that we - due to lack of time /
> resources - will not find the way back to our own Apache
> implementations and will stick with smallrye for a long (?) time
> perhaps.

Correct.  And as mentioned, not finding our way back to our own Apache 
implementations has already been the status quo.

> People are eager to use EE9 / Jakarta namespace and TomEE isn't really
> ready for it, yet. With the latest M7 version, users cannot start new
> projects as testing possibilities are super limited.
> 
> Btw.: I am unsure, if we are still using Hibernate Validation in the
> current TomEE 9-M8 Snapshot. But if we do, we already broke the
> "everything from apache"-credo for the sake of getting the
> certifaction. 

Our certified distribution (Plume) used EclipseLink instead of OpenJPA, Mojarra 
instead of MyFaces and Hibernate Bean Validation instead of BVal.


-David

Re: TomEE MicroProfile and Jakarta

[Zowalla, Richard]

So we basically have to options (if I understand the discussion
correctly):

(A) Put some effort / resources into upgrade our MP impls to the latest
versions to fully support Jakarta namespace. From my understanding
maintaining these impls is a bit PITA as MP tends to break its API
every few months, right? It will take some time, effort and resources
to catch up.

(B) Use existing MP impls to make "fast" progress on the TomEE 9.x
side, which breaks the "we use apache impls"-credo but enables a faster
move forward. I see the danger here that we - due to lack of time /
resources - will not find the way back to our own Apache
implementations and will stick with smallrye for a long (?) time
perhaps.

People are eager to use EE9 / Jakarta namespace and TomEE isn't really
ready for it, yet. With the latest M7 version, users cannot start new
projects as testing possibilities are super limited.

Btw.: I am unsure, if we are still using Hibernate Validation in the
current TomEE 9-M8 Snapshot. But if we do, we already broke the
"everything from apache"-credo for the sake of getting the
certifaction. 

As I am too new to the whole context / strategy thing, I read this
discussion with great interest but do not have a strong opinion
regarding (A) or (B).

Gruß
Richard


Am Freitag, dem 01.04.2022 um 08:27 +0200 schrieb Romain Manni-Bucau:
> The risk for TomEE (IMHO indeed) is that, using smallrye, you break
> the
> core value "apache" or at least "owned by apache" and break the other
> core
> value "lightweight" since it comes with a tons of uneeded stuff and
> implementation is not even JAXRS friendly (it breaks literally jaxrs
> and
> cdi at multiple levels) so it can mean contributing to smallrye which
> means
> at the end asking mircoprofile to not be a spec but just an
> implementation
> and TomEE to stick to a dedicated MP distro (not in all others) to
> not kill
> itself - not saying it does not makes sense but it is what it means
> concretely.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> 
> 
> Le jeu. 31 mars 2022 à 21:36, David Blevins 
> a
> écrit :
> 
> > It would be great to see us have compliant MicroProfile
> > implementations
> > somewhere in Apache; Geronimo, TomEE, CXF.  It's still my personal
> > preference --  It makes very little sense to go through the effort
> > to
> > create a spec and tck to enable multiple implementations that can
> > compete/innovate and then wind up with just one implementation in
> > the
> > industry.
> > 
> > That said, from a TomEE perspective we're struggling to keep up
> > with all
> > specs, Jakarta EE and MicroProfile.  Part of that is we do try to
> > uniquely
> > implement specs, while everyone else just uses the exact same
> > implementation.  We're not really playing the same game.  We would
> > need
> > more resources than the competition to compete in the way we have
> > been
> > attempting.  However, because we're behind, we end up with fewer
> > resources
> > and larger gaps between implementations and over time our goals
> > becomes
> > harder, not easier.
> > 
> > I wonder if we should switch to the SmallRye implementations where
> > needed.  Not because we've given up hope of having Apache
> > implementations,
> > but because if we assume our desire to do the implementation work
> > here is a
> > constant and we know the time to get there will some number of
> > months and
> > that will likely be after complete our Jakarta EE spec work, which
> > is also
> > some number of months... we're basically talking sometime
> > 2023.  The
> > question then becomes, how do we want to spend our time till
> > then?  Do we
> > want to spend it in a compliant state or a non-compliant state?
> > 
> > If we spend the next year and change in a compliant state, using
> > the
> > SmallRye impls where needed until we've created compliant Apache
> > versions,
> > then we are competitive and will gain resources.  The date on which
> > we
> > would have resources to create those Apache implementations would
> > likely be
> > sooner.  If we spend the next year and change still not in a
> > compliant
> > state (as we've been since 2020), then we'l continue to take a
> > resource hit
> > and the date on which we would have resources to create those
> > Apache
> > implementations would likely be later.  There are also other risks
> > with
> > this approach.
> > 
> > So though it may seem backwards my gut says, unless we get a
> > dramatic
> > influx of resources from nowhere, we should use SmallRye where we
> > need
> > until we have the time to dedicate to the Apache implementations.
> > 
> > 
> > -David
> > 
> > 
> > > On Mar 31, 2022, at 12:44 AM, Jean-Louis Monteiro <

Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache

[Zowalla, Richard]

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 
> > 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.blev...@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 

Re: TomEE MicroProfile and Jakarta

[Romain Manni-Bucau]

The risk for TomEE (IMHO indeed) is that, using smallrye, you break the
core value "apache" or at least "owned by apache" and break the other core
value "lightweight" since it comes with a tons of uneeded stuff and
implementation is not even JAXRS friendly (it breaks literally jaxrs and
cdi at multiple levels) so it can mean contributing to smallrye which means
at the end asking mircoprofile to not be a spec but just an implementation
and TomEE to stick to a dedicated MP distro (not in all others) to not kill
itself - not saying it does not makes sense but it is what it means
concretely.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 31 mars 2022 à 21:36, David Blevins  a
écrit :

> It would be great to see us have compliant MicroProfile implementations
> somewhere in Apache; Geronimo, TomEE, CXF.  It's still my personal
> preference --  It makes very little sense to go through the effort to
> create a spec and tck to enable multiple implementations that can
> compete/innovate and then wind up with just one implementation in the
> industry.
>
> That said, from a TomEE perspective we're struggling to keep up with all
> specs, Jakarta EE and MicroProfile.  Part of that is we do try to uniquely
> implement specs, while everyone else just uses the exact same
> implementation.  We're not really playing the same game.  We would need
> more resources than the competition to compete in the way we have been
> attempting.  However, because we're behind, we end up with fewer resources
> and larger gaps between implementations and over time our goals becomes
> harder, not easier.
>
> I wonder if we should switch to the SmallRye implementations where
> needed.  Not because we've given up hope of having Apache implementations,
> but because if we assume our desire to do the implementation work here is a
> constant and we know the time to get there will some number of months and
> that will likely be after complete our Jakarta EE spec work, which is also
> some number of months... we're basically talking sometime 2023.  The
> question then becomes, how do we want to spend our time till then?  Do we
> want to spend it in a compliant state or a non-compliant state?
>
> If we spend the next year and change in a compliant state, using the
> SmallRye impls where needed until we've created compliant Apache versions,
> then we are competitive and will gain resources.  The date on which we
> would have resources to create those Apache implementations would likely be
> sooner.  If we spend the next year and change still not in a compliant
> state (as we've been since 2020), then we'l continue to take a resource hit
> and the date on which we would have resources to create those Apache
> implementations would likely be later.  There are also other risks with
> this approach.
>
> So though it may seem backwards my gut says, unless we get a dramatic
> influx of resources from nowhere, we should use SmallRye where we need
> until we have the time to dedicate to the Apache implementations.
>
>
> -David
>
>
> > On Mar 31, 2022, at 12:44 AM, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
> >
> > Hi,
> >
> > Small update regarding jakarta namespace switch and MicroProfile. Adding
> > Geronimo dev@list because we are using most of the Geronimo
> implementations
> >
> > In order to migrate, we have created a shaded version of all MicroProfile
> > APIs to relocate all javax to jakarta. It worked but it's causing some
> > issues with TCK. They are not relocated so of course, all TCK are
> failing.
> >
> > I wanted to see how far we are regarding our implementations, so I went
> > ahead and updated all TCK to the latest version (and compatible with the
> > Jakarta namespace).
> >
> > The other option would be to grab all the TCK and create their equivalent
> > in jakarta namespace using the same approach as for the APIs.
> >
> > What are your thoughts?
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
>
>