| Re: [jakarta.ee-community] About Profiles |
Hi,On Mon, May 7, 2018 at 5:05 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:Here is the problem with not having a profile. If there is no profiles than every vendor (including OSS) has to implement the entire platform in order to be compliant.So then the first question is perhaps; who wants profiles and benefits from it? Is a profile intended for vendors or for users?The second question, which vendor actually full implements the entire platform itself now? Even IBM (arguably the biggest vendor) bundles various component jars instead of developing everything from scratch.I can’t just implement what I want and still claim Jakarata EE compliance.But isn't that the entire idea of compliance? If you just implement whatever you want, how can that even be compliant with anything?Has there ever been a discussion about this regarding say the C++ std lib? I.e. someone only wants to implement c:out, and then still claiming C++ compliance? What does it even mean then? (I know this example is taken to the extreme, but it's just an example).I have to implement the full platform and all of its APIs.As mentioned above, I don't think you have to. Most APIs can just be taken from open source and bundled.That’s too much to ask of many vendors and is why there was consolidation of vendors in Java EE. Instead, Profiles allow vendors to achieve compliance with a standardized subset, a Profile, as an option rather than entire platform. A vendor can choose to be certified for the entire platform or a profile.I'm not sure if a bloated product line-up with a dozen profiles really makes things easier for users.Say I have an application that's written against Jakarta EE profile 23. Will it run against Jakarta EE profile 14? If vendor 56 supports profiles 4, 7, 16 and 21, can I run an app for that also on vendor 33's product which supports profiles 3, 8, 9 and 12?Kind regards,ArjanOn Mon, May 7, 2018 at 8:58 AM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:Hi,After some thinking about it as well, I feel we really don't need many profiles at all.Just the full profile should be enough, and a legacy free profile that excludes the stuff nobody wants to implement just for compliance (such as EJB CMP), and which can slice within specs as well (ala EJB-lite, to remove packages, classes, or methods within classes).The perfectly suited "individual profile" can then be generated by users via a tool which prunes all the specs they personally don't need from a given full or legacy free server. The result of such pruning is a new server that physically doesn't contain the specs that bother people. So for instance if people are bothered by the idea that JSF is in their server, they can run this tool and then the Mojarra jar won't be present at all in the resulting new server.Thoughts?Kind regards,Arjan______________________________On Mon, May 7, 2018 at 3:45 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:After thinking more about this and discussing this with David Blevins I’ve come to believe that there should be a “includes everything” full profile which ensures that all component specifications work together with subset profiles that represent only slices of the full profile.Some vendors (including OSS) might choose to implement the Full Profile - the reference implemenation should do this for sure - but many will choose to implement only a sub-profile (e.g. Web Profile, IoT, REST ). A vendor can be certified according to a sub-profile and need not implement the Full Profile. The sub-profiles would be standardized. Any time a new specification or API is added to Jakarta EE it must first interoperate with the Full Profile. Once it does it can be included the specification of any sub-profile.On Thu, May 3, 2018 at 5:41 PM Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx> wrote: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@eclipse.org <jakarta.ee-community-bounces@eclipse.org > 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@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
> --
> Richard Monson-Haefel
> http://twitter.com/rmonson
> http://www.tomitribe.com
> http://www.tomitribe.io
>
> _______________________________________________
> 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-communit y
_______________________________________________
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-communit y
_________________
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-communit y
--
_______________________________________________
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-communit y
_________________
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-communit y
--
_______________________________________________
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-communit y
_______________________________________________
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