[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-community] About Profiles
|
I agree too many profiles can be confusing, but I do think we need to have at least a few if not for any other reason than for marketing. Adding a core and microservices profile makes total sense from that perspective. To be completely honest, modularity is needed for similar reasons. Whether or not it is a practical need, skeptics constantly beat up Java EE due to the absence of modularity.
We need to try and remove these weaknesses going forward if Jakatata EE is to succeed. I know it's easier said than done, but leaving these things as talking points competitors can exploit for negative marketing undermines everything else we do. It's tiresome to lose real world adoption opportunities not because of solid technical reasons, but because the technology leaves itself vulnerable in terms of marketing.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: Adam Bien <abien@xxxxxxxxxxxxx>
Date: 5/3/18 1:06 AM (GMT-05:00)
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: [jakarta.ee-community] About Profiles
1. From the usability, dev experience, we should aim for as few profiles as only possible.
My selling point for Java EE in the past was the simplicity. There was only one choice -- the Full Profile -- (there were no measurable advantages of WebProfile, so we never used that) what was appreciated by the developers. There were no unique "snow lake" project in the past what was good for long term maintenance and corporate developers self support. With the "one dependency" idea, even startups used Java EE with the "time to market" advantage. There was no evals or dependency fiddling. We started with use case implementation at the day one.
2. From the runtime vendor perspective, modular platform is easier to maintain, develop and is good for the ecosystem. So vendors should modularize the Java EE platform as far as it is useful. However this should be an internal implementation detail.
IMO we should have one "main profile" which comprises similar functionality to the "full profile" in Java EE (of course without SOAP :-)) which should cover the 80% of the main use cases. This profile could be implemented as a BOM (micropofile does that, what is really convenient to use).
Exceptional usecases (e.g. scenarios like NetFlix with 10k of microservice instances) could be covered by specific profiles.
_______________________________________________
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
