EAR support in Jakarta EE is a genuinely complex topic. I see plenty of customers still using them, so I think dropping them outright is a no-go. That said, honestly I am not sure folks that do use it are using it for the right reasons. What I am sure of is that EAR support in Java EE is woefully underspecified.
Now, we do have to keep in mind that the concept of the EAR pre-dated things like Maven modules and now JPMS. In recent years what I have seen is that customers are successfully doing what they used to do with EAR deployments through Maven modules and WAR (or lately fat jar) deployments.
My view is that Jakarta EE should mostly focus on WAR deployments for now, leaving EAR support largely as-is, with maybe some minor improvements where time permits. I definitely think vendors should help out EAR users however they can, perhaps adding proprietary features when it makes sense.
I do think however that going forward Jakarta EE should take JPMS very seriously. It's the real answer to the fat jar stop gap and would be a true differentiator for Jakarta EE implementations. It can also help make Java EE implementations even more lightweight by removing the need to ship another module system like OSGi. Now, I fully realize JPMS itself maybe underspecified, so maybe we can get the JDK folks to invest some more effort there.
Personally I would love to hear thoughts from vendors with regards to JPMS, especially on how they see it aligning with WAR and fat jar deployment approaches.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
Date: 4/28/18 4:06 AM (GMT-05:00)
Subject: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?
to my background: I have been developing enterprise applications
for more than 10 years, mostly as EARs. So I am mainly a User of
EE and was never part of a EE working group. My opinion about
EARs after years is: It's an awful disaster if you're trying to
develop an ear platform independently. So why should it be
Today I wonder what can be achieved with an EAR, which could not
be achieved easier and clearer with a clean microservice
So I'm suggesting removing EAR support from Jakarta EE. This
makes the platform easier to learn and more lightweight.
If you like, you can read the following discussion. It's about
the question of how to package shared EJB libraries in one ear.
And it shows how awkward it is to talk about EAR deployment
What is your opinion about the future support of the concept of
To change your delivery options, retrieve your password, or unsubscribe from this list, visit