| Re: [jakarta.ee-community] About Profiles |
I assume that profiles support inheritance. It means that MicroProfile must support Servlet, which I don’t agree.Here is what I am suggesting:Full Profile - includes all components (active and deprecated). Best for backwards compatibility.Main Profile - includes only active components (doesn't include deprecated components).Micro Profile - includes only Micro Profile components. Suitable for microservices.Custom Profile - includes only some components. It's up to implementations which components to include. Nice for new vendors.Components can be:active - solid API, recommended for using in devdeprecated - solid API, not recommended for using in dev. Will be removed in next platform versionsoptional - not solid API, not recommended for production usage. Will be included in next version of the platform with high probability.Each profile above can include optional components.BOM pom should be provided for all profiles except custom.It’s up to vendors to provide modularised implementations or not. Modularized I mean ability to build a server with only specified components.Thanks,DmitryOn 3 May 2018, at 13:36, Rudy De Busscher <rdebusscher@xxxxxxxxx> wrote:I have mixed feelings about all those profiles.The idea of Java EE was that you just had anything, without the need to think what you need to add to the mix.Maybe we should have a few- Core (Servlet + CDI)- MicroProfile- Web- Full(or whatever the names can be)But what happens when we have more profiles then vendors? Will each vendor just concentrate on one profile and thus we lose the ability to swap between servers?And the situation where we have only a servlet platform and that you can add any library will not work. Will all those combinations work? What about dependencies? (for ex, we get the situation that each spec will have his bean model because it needs to work standalone), conflicts between libraries (we have had our share of that in the past), etc ...Rudy______________________________On 3 May 2018 at 13:26, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:For non-functionals practically profiles don't achieve a lot. For example Payara Micro contains most of web profile + batch, concurrency apis, JCA and JMS client and weighs in approx. 70MB jar and 30MB JVM heap usage and boots in 2-3s without clustering. When we looked at shipping a pure microprofile version we could perhaps shave 30-40% off some of those numbers but nothing that made the effort super worthwhile.
However for compliance profiles help to enable vendors to ship a subset of specs without having to implement everything. Therefore I agree with Jason's view that it is compliance restrictions that likely need relaxing with the ability to state levels of compliance. The tricky piece is relaxing compliance while maintaining portability. My suggestion would be for max 3- 4 profiles. Something like; nucleus (very minimal core), web, legacy free (full), Full whereby each is a superset of the previous. Then it is up to vendors, if they so wish, to add mechanisms to layer additional specs on each and compliance shouldn't be affected by adding additional specs. So Full is naturally also nucleus, web and legacy free compliant as well. Also adding newer spec versions that are backwards compatible should also maintain compliance as long as the previous CTS/TCK can still be passed.
One of the advantages of Java EE is that it is all there and the developer doesn't have to worry about fiddling around building their own runtime. Now I know a vocal number of developers do want to do this and other frameworks push their marketing at these people. There are also a large number of developers that don't care about assembling runtimes and just want to ship business functionality as quick as possible. For them there are a number of up-sides to the JavaEE model, portability, simplicity and let's not forget security. Having a single versioned baseline runtime in production is way simpler to patch than trying to work out which vulnerable libraries are packaged up into a hand crafted executable Uber Jar. We need to market confidently the benefits of the Jakarta EE model. Adam does a lot of that well with his work on thin wars and their advantage for docker containers etc.
Steve
-----Original Message-----
From: jakarta.ee-community-bounces@eclipse.org <jakarta.ee-community-bounces@eclipse.org > On Behalf Of Adam Bien
Sent: 03 May 2018 12:00
To: Jakarta EE community discussions <jakarta.ee-community@eclipse.org >
Subject: Re: [jakarta.ee-community] About Profiles
Marketing is great, but the purpose should be crystal clear.
Otherwise we get more profiles than use cases. IMO "no profiles" with an ultra thin platform would be the best case.
Profiles imply the core is bloated and therefore we need to split it in order to improve non-functional requirements.
> On 3. May 2018, at 12:56, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
>
> 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@eclipse.org >
> 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@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
_______________________________________________
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