| Re: [jakarta.ee-community] About Profiles |
My view:
- have a Full profile
- have multiple modules that group several hugely related specs
- modules can be combined
- all modules combined would be equal to the Full profile
Full Profile - the simplicity Adam seeks
Maybe have a legacy-free profile too (without SOAP, remote EJB or even without EJB if other specs can provide the essential features) - WebProfile is very close to this
Modules would enable users to take only what they need but wouldn't be as prominently promoted as the Full/legacy-free profiles.
Each individual spec could be a module - the essential problem with that is it's hard to test all combinations of specs. So less granular modules could decrease the number of combinations dramatically while allowing picking only what's needed.
Cheers,
Ondrej Mihályi
Senior Payara Service Engineer
Payara Server – Robust. Reliable. Supported.
E: ondrej.mihalyi@xxxxxxxxxxx | T: +1 415 523 0175 | M: +421 902 079 891
----------------------------------------------------------------------------------------------------------------------
Payara Services Limited, Registered office: Unit 11, Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ
Registered in England and Wales: 09998946 | www.payara.fish | info@xxxxxxxxxxx | @Payara_Fish
From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
Sent: 03 May 2018 16:15:11
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] About Profiles_______________________________________________--+1 . I agree with the Facade argument as well. The CDI is, in essence, the Facade while the underlying details are defined by the abstract Core.
On Thu, May 3, 2018 at 9:07 AM Adam Bien <abien@xxxxxxxxxxxxx> wrote:
> On 3. May 2018, at 16:02, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:
>
> I understand where Adam in is coming from in terms of simplicity - I have wrestled with how to accommodate multiple profiles and simplicity as well. I do not think, however, that supporting multiple profiles makes for an inherently more complex platform. On the contrary.
I'm coming from projects :-)
The abstract and subclass analogy is good. However, both should be hidden behind a facade. The developers should only know the facade -> and what is hidden behind are the implementation details.
I'm absolutely convinced we need a thin main profile. This should be good enough for majority of use cases.
All other profiles has to be motivated by application types or use cases.
>
> If Jakarta EE can define a Core of absolutely necessary technologies (e.g. CDI) than profiles, which are, by design, interoperable with the core and other profiles can be defined and used as needed.
>
> I like to think of the Core as the abstract class (sorry functional purists but I’m going OO on this analogy) and the profiles as interfaces that can be optionally implemented by vendors. The vendor implements a concrete version of the Core, the behavior of which is strictly specified and certified, and then zero or more of the profiles. When a profile is specified we ensure that the TCK for that profile requires interoperability with the Core and if all profiles work as specified with the Core than they will work together without compatibility issues. For the first time, we have full control of the specifications and - just as importantly - the TCKs.
>
> The Core + Profiles approach allows the platform to evolve according to the needs of the industry instead of according to the needs of any one problem domain. Right now everyone is saying that SOAP-based web services are dead so we should ditch that, but in 2004 that opinion would have been viewed as moronic. What technologies today do we feel are critical that will be obsolete in 10 years? We don’t know. Profiles give us the flexibility to support technology and problem domains without constraining the platform as a whole.
>
> On Thu, May 3, 2018 at 12:06 AM Adam Bien <abien@xxxxxxxxxxxxx> 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@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
> --
> Richard Monson-Haefel
> http://twitter.com/rmonson
> http://www.tomitribe.com
> http://www.tomitribe.io
>
> _______________________________________________
> 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
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