TomEE 9 with Jakarta EE 9

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

TomEE 9 with Jakarta EE 9

Jean-Louis MONTEIRO
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?
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
   --
    Jean-Louis Monteiro
    http://twitter.com/jlouismonteiro
    http://www.tomitribe.com
Reply | Threaded
Open this post in threaded view
|

Re: TomEE 9 with Jakarta EE 9

Daniel Cunha
Hi!!

personally, I like the idea to create a maintenance branch for TomEE 8.x
and move master to 9.x.


Em qui., 28 de jan. de 2021 às 08:50, Jean-Louis Monteiro <
[hidden email]> escreveu:

> 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?
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>


--
Daniel "soro" Cunha
https://twitter.com/dvlc_
Reply | Threaded
Open this post in threaded view
|

Re: TomEE 9 with Jakarta EE 9

Daniel Dias Dos Santos
Hi,

I like the idea of move to master 9.x.

On Thu, Jan 28, 2021, 10:12 Daniel Cunha <[hidden email]> wrote:

> Hi!!
>
> personally, I like the idea to create a maintenance branch for TomEE 8.x
> and move master to 9.x.
>
>
> Em qui., 28 de jan. de 2021 às 08:50, Jean-Louis Monteiro <
> [hidden email]> escreveu:
>
> > 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?
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
>
>
> --
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
>
Reply | Threaded
Open this post in threaded view
|

Re: TomEE 9 with Jakarta EE 9

Rémy Maucherat
In reply to this post by Jean-Louis MONTEIRO
On Thu, Jan 28, 2021 at 12:50 PM Jean-Louis Monteiro <
[hidden email]> 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?
>

Glad to see some possible users for Tomcat 10.0 :)

The plan right now is that the EOL of the Tomcat branch for EE 9 will come
quite soon after EE 10 gets supported (since EE 9 does not bring enough new
functionality). Depending on the support plans you have for EE 9, this may
not work out for you. Do you plan a quick move to EE 10 ?

Rémy


> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
Reply | Threaded
Open this post in threaded view
|

Re: TomEE 9 with Jakarta EE 9

David Blevins-2
In reply to this post by Jean-Louis MONTEIRO

> On Jan 28, 2021, at 3:49 AM, Jean-Louis Monteiro <[hidden email]> 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 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TomEE 9 with Jakarta EE 9

David Blevins-2
> On Feb 8, 2021, at 2:00 PM, David Blevins <[hidden email]> wrote:
>
> 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.

Here's a reference.  Nishant did a conversion April last year.  There are so many merge conflicts now that Github won't even try to show any insights.

 - https://github.com/apache/tomee/pull/633

If you hover over the greyed-out "Resolve Conflicts" button it just says the conflicts are too complex to resolve in the web editor.


-David


smime.p7s (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TomEE 9 with Jakarta EE 9

David Blevins-2
In reply to this post by Jean-Louis MONTEIRO
> On Jan 28, 2021, at 3:49 AM, Jean-Louis Monteiro <[hidden email]> 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 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TomEE 9 with Jakarta EE 9

Jean-Louis MONTEIRO
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 <[hidden email]>
wrote:

> > On Jan 28, 2021, at 3:49 AM, Jean-Louis Monteiro <
> [hidden email]> 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
>
>
   --
    Jean-Louis Monteiro
    http://twitter.com/jlouismonteiro
    http://www.tomitribe.com