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 <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le jeu. 31 mars 2022 à 21:36, David Blevins <david.blev...@gmail.com> > 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
smime.p7s
Description: S/MIME cryptographic signature
