Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?

Hi Dennis,

I agree with you - EARs can be a fine concept for assembling application modules. I use it by my own. But the problem starts when you try to run the result on different platforms (glassfish/wildfly for example). My discussion [1] was frustrating and we can not name it standard if even payara and wildfly did not interpret it in the same way.

best regards

Ralph

[1]  https://github.com/payara/Payara/issues/2508#issuecomment-385129757



Am 29.04.2018 um 01:20 schrieb Dennis Gesker:
HI Ralph:

Our group finds EARs extremely useful. Particularly early in the implementation of our product roadmap. Our process tends to be aggressivly iteratative. So, we prototype very quickly. 

Sometimes, features we initially intended to isolate (microservice but with the benefit of all the goodies of a full EE container) find their way back from a WAR back into the core EAR and vice/versa meaning elements that seemed initially to benefit from more tight coupling end up refactored our to WARs.

I'd love to keep it in the standard as it provides a proven architectural approach to project assembly but doesn't prevent more modular/distributed/micro patterns.

Keeping it provides utility. Keeping it doesn't prevent other patterns.

BTW, I'm also in the "cheap seats" meaning not on the working group but would love to help if there is room for input/participation from small fry shops.

Cordially,
Dennis

 


On Sat, Apr 28, 2018, 2:07 AM Ralph Soika <ralph.soika@xxxxxxxxx> wrote:

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


_______________________________________________
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

--

Imixs Software Solutions GmbH
Web: www.imixs.com Phone: +49 (0)89-452136 16
Office: Agnes-Pockels-Bogen 1, 80992 München
Registergericht: Amtsgericht Muenchen, HRB 136045
Geschaeftsführer: Gaby Heinle u. Ralph Soika

Imixs is an open source company, read more: www.imixs.org


Back to the top