> On Jan 28, 2021, at 3:49 AM, Jean-Louis Monteiro <[email protected]> > wrote: > > Hi, > > We started the work on Jakarta EE 9 a few months ago. So far we are in good > shape by only applying the transformer in our code. But it looks like we > are facing some limitations. > > 1/ libraries we are using Tomcat, Mojorra, EclipseLink to name a few > already have Jakarta EE 9 compliant versions, which are more complete than > what we could do with the transformer. > > 2/ only creating zip files is restrictive. People can't use the > EJBContainer to unit test their code because we don't publish Maven > artifacts. TomEE embedded and other flavors of TomEE are not available > anymore. > > I'm wondering if at this moment, it would not be better to create a > maintenant branch for TomEE 8.x and move master to 9.x > > We could just do the dependency upgrades in there and any API changes due > to dependency upgrades. > > We would only keep working on TomEE 8 and cherry pick or backport > everything into TomEE 9.x so we have minimal changes between the 2 and we > don't spread our effort on multiple source trees. > > What do you think?
Once we branched and changed the namespaces and dependencies we'd have conflicts and often wouldn't be able to use git cherry pick or merge without manual cleanup. The short version: - My fear is the little time we have for new development now gets immediately chewed up by new maintenance costs We definitely need to do it at some point, but it still feels too early to start paying that maintenance cost now. The long version: I think the 8.x branch will likely be the main binary most users consume for at least the next 2-4 years. Some reasons: - there aren't new features in Jakarta EE 9 - All the Cloud and Tools vendors aren't yet supporting it - libraries like PrimeFaces, etc need to catch up I think it'll be another year for all of the above three to show up; new features, good tooling support, selection of 3rd-party libraries. Then once they show up I think we're looking at another year minimum before anyone has something in production at scale. The above minimums feel pretty aggressive to me actually. Given how long 8 will live, my personal perspective is I'd like to see it be in as good a shape as possible before we branch. Some things on my wish list for the javax version: - Complete Jakarta EE 8 Web Profile support - Catch up to MicroProfile 4.x (we're at 2.1) - Get a good chunk of Jakarta EE 8 Full Profile tests passing - Get our documentation in order (i.e. leverage David Jencks' work) - Try to improve startup a bit (optional, just something I want to work on this year) We can of course leave 8 as-is, branch and do all these in 9. My concern there is if we do all of these things in 9 and not 8 as well, the codebases will have diverged even beyond namespace and cost of merging things be even higher. As many people will never migrate from javax-to-jakarta, 8 will have an exceptionally long maintenance life. Conclusion on the long version is I don't see any path that gets us out of pain associated with the namespace change. I have other thoughts on what we could potentially do, but I'll put those in another email as this one is already long. -David
smime.p7s
Description: S/MIME cryptographic signature
