Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?
I see little reasons to use EARs on new projects and some specs (CDI at least) have suffered difficulties from their class visibility particularities.
Please note the Web Profile already supports only WAR deployment and also leave behind some less frequently used technologies.
Implementors will have more elaborated oponions, but I think EARs should be deprecated (not removed) and made optional on some specific profile in the near future.
Times are changing and for Jakarta EE to be perceived as a lean technology we will need some kind of composable profile (think of WildFly Swarm or Liberty) or "legacy-free" profile (I think Payara had some plans for that).
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
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit