Re: [jakarta.ee-community] About Profiles

[Werner Keil <werner.keil@xxxxxxxxx>]

Hi,

The desire to keep the number of profiles low has plagued Java EE at least since EE 6. And having been the only Individual (except Antonio I believe) in the EE Umbrella EG from 6 to 8 I know most of that history. I was beside a few others (like Antonio or David) vocal about adding a few more profiles, which was not heard by vendors till some of them came up with the MicroProfile idea. 

Having a "free profile" which is pretty much like Spring is not a bad thing, but I guess at least 2 or 3 others can't hurt. Large enterprises unlike some "hippy startups" or cool social media players depend on compatibility. And MicroProfile is the best or rather worst example how compatibility is almost impossible to guarantee. And most implementations won't even work in the "Full Profile" containers by the same vendors. 

That BOM also never existed for MicroProfile. It so far merely is a Parent POM to help new MP features use the minimal necessary standards but it does not work on the outside for developers trying to consume and use MicroProfile. Such a BOM still does not exist, you can see what's been discussed over the past 2 quarters in this thread: https://groups.google.com/forum/?hl=en#!topic/microprofile/DAemBIWP9mI Following others on the same subject pretty much since a year earlier when Eclipse had accepted it.

Werner

Werner Keil | JCP Award Winner, JSR 385 Spec Lead | Eclipse UOMo Lead, EE4J Committer | Apache Committer | DWX '18 Track Chair, AdBoard Member

Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @TamayaConf | @OpenDDR | #EclipseUOMo

Skype werner.keil

On Thu, May 3, 2018 at 10:28 AM, Dimitris Andreadis <dandread@xxxxxxxxxx> wrote:

In general, I like the idea but there are two caveats:

a) smaller players can't/wont implement the full spectrum of Jakarta EE, so they can claim certification.

b) when having a composable platform, in addition to testing everything together (the platform) you still need to test specific APIs combinations that represent particular popular usecases to make sure they work well together, and that naturally leads to some definition of profiles.

/Dimitris

Dimitris Andreadis
Engineering Director
Red Hat JBoss EAP/WildFly

On 03/05/2018 07:06, Adam Bien wrote:

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@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://dev.eclipse.org/mailman/listinfo/jakarta.ee-community