> 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.
Note: much of this email involves having something like the proposed tomee-9 branch, just with a few select modules rather than a full duplication of all code. # Using Tomcat 10, Mojorra, EclipseLink, etc Strongly agree with #1 and the desire to use Tomcat 10, MyFaces, Mojarra, EclipseLink and the official 'jakarta' versions where possible. I think we could do that forking a few modules from the main `tomee` repo to the `tomee-jakarta` repo. Specifically: - tomee/tomee-plus-webapp - tomee/tomee-plume-webapp - tomee/tomee-microprofile/tomee-microprofile-webapp - tomee/apache-tomee - tomee/tomee-webapp # TomEE Embedded In terms of embedded use I've had it in my radar for quite a while to kill any direct use of OpenEJB/TomEE dependencies for embedded use. It was never really documented which TomEE/OpenEJB modules you really should be importing to use our EJBContainer/ApplicationComposer and get the same features as a full TomEE server. For just plain OpenEJB embedded, just `openejb-core` is fine. If you want to test JAX-RS, then the answer has always been unclear; typically it's `openejb-core`, `openejb-cxf-rs` and a handful of CXF dependencies. When we add things like MicroProfile support in our servers, it's one more set of dependencies Embedded people have to go and hunt down in hopes to get something working. I always felt it was a shame we didn't have a simple dependency people could use that lined up with the server dists. That's why I put the work into code that creates these artifacts: - boms/tomee-plus - boms/tomee-microprofile - boms/tomee-plume - boms/tomee-webprofile These are all generated from the zips and can completely replace `openejb-cxf-rs` as a maven dependency. None of these have any transitive dependencies. As we add things like MicroProfile support, they get updated and embedded users can leverage that without having to go through any dependency pain. I didn't get as far as converting all our examples over to use these new deps, but we should do that. These could help our Jakarta EE 9 problems as they are generated from the zips. We could copy these into the `tomee-jakarta` repo and get complete embedded versions of all our Jakarta EE 9 dists. To make that really actionable, we probably want to invest in the generator a bit and actually make it a Maven plugin. Right now a human has to run it. This is something we should do anyway. # TomEE Arquillian & Maven Plugin I don't have any silver bullets for this one. I have noticed it be at times painful to have the Arquillian adapters and Maven Plugins sitting in the main TomEE source. There have been times where there is a cool new feature in the TomEE Maven Plugin that I'd like to use, but can't as I'm working with a project using an older TomEE version and upgrading isn't possible. There have been times when I wanted to use the TomEE Remote Arquillian adapter to test a few different TomEE versions, but it gets ugly as the TomEE Arquillian adapters have dependencies on TomEE libraries themselves. Again, not something tied to Jakarta EE 9, but I've long felt they needed a rewrite so they don't depend on server libraries. I've also wondered if they shouldn't be in their own repository and released separately. I kind of see this TomEE 8 vs TomEE 9 situation as more indications that this might be something we want to do. This would be a significant investment, but could be worth it. The trickiest part would be the TomEE Embedded Arquillian adapter, but it also shares the same limitations as the other embedded support I mention: dependencies you need are unclear; when we add things like MicroProfile support, these features won't work embedded without expert-level knowledge of the code and required deps; all the TomEE flavors can work embedded, but we awkwardly have one TomEE embedded Arquillian setup, which I don't think actually matches any of our established TomEE flavors. No idea if it is possible, but it would be great if you could simply specify just two dependencies; the tomee-embedded-adapter and the corresponding boms/tomee-plus, etc, dependency. All of this is brainstorming. Thoughts? -David
smime.p7s
Description: S/MIME cryptographic signature
