Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Why not dropping EARs in Jakarta EE?

FWIW on the WildFly side we favor augmentation and/or interpretation, as the descriptor is compiled with the jar, and may not be under their full control (an SE jar they expect to *just work* with EE apps).

On Apr 30, 2018, at 10:36 AM, Jason Greene <jason.greene@xxxxxxxxxx> wrote:

I agree that we need to look to standardizing JPMS usage after Jakarta EE8, as mapping it to EE isn’t clear/straightforward and therefore a portability challenge. As an example, one challenge is that JPMS’ strong encapsulation resists/prevents introspection and IoC patterns critical to EE. I suspect for usability reasons it will be desirable to augment user provided module specs to support EE interaction. Although it’s also possible to require the user to follow a particular pattern  (e.g. they must define their module as open to a spec defined intermediary, else their app fails). 


On Apr 30, 2018, at 10:17 AM, reza_rahman <reza_rahman@xxxxxxxxx> wrote:

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 --------
From: Ralph Soika <ralph.soika@xxxxxxxxx>
Date: 4/28/18 4:06 AM (GMT-05:00)
Subject: [] 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 called 'standard'?

Today I wonder what can be achieved with an EAR, which could not be achieved easier and clearer with a clean microservice architecture?

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 questions.

What is your opinion about the future support of the concept of EAR?


_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top