| Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE? |
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@xxxxxxxxxxx>
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community