Hi all, I am strongly +1 for moving forward with it, i.e. time to move on with master.
There is definitley the need for some artifacts (arquillian, app composer), which are not covered by the byte-code approach and which are required to migrate (fully w/o byte code transformation) to the jakarta namespace :) Although - I think it is clear to everyone - the 8.x branch will (obviously) stay for a couple of years as it is the last javax namespace supporting release. Gruß Richard Am Dienstag, dem 08.02.2022 um 00:04 +0100 schrieb Jean-Louis Monteiro: > Hi all, > > We have discussed it a couple of times here and there. I'd like to > open a > dedicated thread for it. > > EE 9 has been released and we have created a TomEE 9.x milestone to > pass > the TCK. The approach to do bytecode changes to support javax -> > jakarta > namespace changes proved to work but it's also been more complex than > expected. We have a limited fork with limited features. We don't > support > nearly as much as we do in the 8.x branch. > > The goal was to decrease the maintenance cost for the community, but > in > reality I fear we are on the opposite path. > > I'd like to create a TomEE 8.x maintenance branch where we keep > fixing > stuff, upgrading libraries and do as many releases as possible and as > long > as we can to support javax namespace. I know it's the last compatible > version so the topic is not when TomEE is going to be EOL. > > But if we do that, we could move master to TomEE 9 and start merging > back > all changes we did in the fork and finally create an EE 9 final > release. > > EE 10 is around the corner, if we want to keep supporting EE and > being > certified, we need to avoid big jumps. > > What does the community think? > > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com
smime.p7s
Description: S/MIME cryptographic signature
