Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?

[arjan tijms <arjan.tijms@xxxxxxxxx>]

>(4) EAR files use a defined standard.

This is a bit of the issue. They are theoretically standard, but in practice not so much. Like the application client container and remote EJB, there are a couple of issues, but for years every EE release has basically ignored them.

"Fixing" EARs would be another approach instead of dropping them, but some things like how CDI should behave in an EAR are just hard. I think I've seen some discussions before, and people couldn't really agree with each other.

On Mon, Apr 30, 2018 at 7:41 PM, Thomas Bitonti <bitonti@xxxxxxxxxx> wrote:

Why we should keep EAR files:

(1) Removing EAR files means removing application.xml, and any information which that provides. For two cases (library directory and context root) the removal invites the introduction of a more robust mechanism. In other cases, functionality is simply removed to no apparent benefit. Removed function includes quick module typing, module initialization ordering, and shared entities such as security roles, resource references, and resource factory definitions.

(2) As a basic function, EAR files enable deployments to process multiple finer deployable entities (modules) conveniently as a single unit.

(3) As a more complex function, EAR files enable sharing between modules.

(4) EAR files use a defined standard.

Why we should remove EAR files:

(1) As a practical matter, having multiple EAR files deployed to a single deployment environment is being replaced by placing groupings one or more modules and their shared entities each to their own deployment environment, with any significant sharing occurring within the separate deployment environments. An example of this is the configuration of shared libraries within a Liberty server, in which the environment is defined to contain several modules, and is configured to contain one or more shared libraries, with the modules, the shared libraries, and the per-module use of the shared libraries exposed in the server configuration.

(2) Also as a practical matter, server environments are beginning to abandon EAR -- despite standardization -- shifting to a local non-standard composition mechanism, or to an alternate composition mechanism such as OSGi or JPMS, which, although being defined outside of JavaEE/Jakarte, are standardized.

What seems to be central is the question of whether there should be *any* standard defined mechanism of aggregation, and, if there are, how to being that mechanism "up to speed" to be more effective, and whether there should be a single mechanism or a family of similar mechanisms, in consideration of overlap with standards such as OSGi and JMPS.

Thx!

Thomas F. Bitonti
IBM WebSphere Application Server
(919) 486-0867


Jason Greene ---04/30/2018 11:36:16 AM---I agree that we need to look to standardizing JPMS usage after Jakarta EE8, as mapping it to EE isn’

From: Jason Greene <jason.greene@xxxxxxxxxx>
To: Jakarta EE community discussions <jakarta.ee-community@eclipse.org>
Date: 04/30/2018 11:36 AM
Subject: Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?
Sent by: jakarta.ee-community-bounces@eclipse.org

---

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

-Jason

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)
To: jakarta.ee-community@eclipse.org
Subject: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?


Hi,

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.
https://github.com/payara/Payara/issues/2508#issuecomment-385129757

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

===
Ralph


_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jakarta.ee-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=ub-cj75YRRGUWwNt7JqiFIRRFnWq58p8Cmrc6LhfpTE&m=-N-CO_G1i1HJoSgd1teCZIPNKQbvPT5RZ7qWWi9nsgw&s=Ou_NJgwogTqHHa3H2sAY6-PC2eRrRFMg5XXneKERbHw&e=

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community