Thanks David and all. I understand the drawbacks in terms of time and energy required to maintain both at the same time. We rather focus on improving, cleaning and adding new features.
In terms of current situation, it does not work though. Application Composer, junit integration, EJBContainer API, arquillian, or tomee embedded, nothing works. Java EE has always been perceived as difficult to test, but it was mainly because of the servers/containers. On the other hand, it's always been one big advantage of OpenEJB/TomEE. At the moment, only downloading zip (transformed) works. If we don't want to maintain both quite yet, we need to still improve what we have. Back to you email because I see some common ideas and possible options. See bellow ... -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Tue, Feb 9, 2021 at 2:05 AM David Blevins <[email protected]> wrote: > > 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 > > Yes. The list might be a bit longer because we have integration modules for EclipseLink for instance. But they are quite small. > > # 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. > > +1 but not Jakarta EE 9 specific. > > # 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. > > TomEE Maven plugin should be able to remain as is and work for both. > > All of this is brainstorming. Thoughts? > > > -David > >
