Re: [jakarta.ee-community] A Composable Platform Over Profiles

["Kevin Sutter" <sutter@xxxxxxxxxx>]

+1, Jason!  Allowing for individual
component spec compliance (ie. Servlet x.y) as well as platform compliance
(ie. Jakarta EE x.y) is necessary as we (re)define Jakarta EE.  We
have promoted and followed this approach with our MicroProfile efforts.
 Developers/vendors can claim Config 1.2 compliance separate from
claiming MicroProfile 1.3 compliance, as an example.  This has been
well received by the vendors able to pick and choose which specifications
to support depending on their needs and schedules.  But, I will also
point out that the platform spec (ie. MicroProfile) has also been well
received by customers wishing to get the "matching set" of technologies.

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:      
 Jason Greene <jason.greene@xxxxxxxxxx>
To:      
 Jakarta EE community
discussions <jakarta.ee-community@xxxxxxxxxxx>
Date:      
 05/01/2018 01:11 PM
Subject:    
   [jakarta.ee-community]
A Composable Platform Over Profiles
Sent by:    
   jakarta.ee-community-bounces@xxxxxxxxxxx

---

Over the years there has been vigorous debate about
what makes the perfect profile. “Should spec X be included or not?” “Should
we create a “plus” variant of the web profile?" “How many profiles
is too many?" “How many is too few?" Recent threads you can
see the topic rising again with Stable and Legacy profile proposals, and
debate about whether or not JAX-WS should be part of the platform. 

A related issue is that EE compliance is overly strict. An implementor
must ship exactly what a profile defines, with limited exceptions on variation.
As an example, a certified web or full implementation can’t ship a newer
version of the Servlet API, even though it’s fully backwards compatible.
The default run mode / config of the implementation is also not allowed
to enable a subset of the profile, even though the implementor’s primary
audience may not need all of the specified technologies. 

The idea behind a rigid platform certainly had merit, and it arguably led
to the very strong level of portability across containers we enjoy today.
However, this one-size-fits-all approach just no longer fits the current
state of software, with developers expecting a high degree of application
specific tailoring.

I argue that a better approach would be to define the platform as a palette
of composable standards[1], where profiles define only what must be available
for a developer to choose from, and only limit the version of a given standard
to the minimum that must be provided[2]. Under this model there is less
of a need to define a perfect profile, since it can be freely adjusted
by the developer to fit his or her needs. Instead, all that matters is
that we have a sensible array of choice.

[1] It’s worth noting that this would require the TCK to be split up,
as discussed previously, to facilitate the flexibility required in testing
a near arbitrary combination of standards.

[2] For clarity, the full and web profiles would still be versioned (8.0
etc) as today, this is just a rule softening to support variation.

--
Jason T. Greene
Chief Architect, JBoss EAP
Red Hat



_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jakarta.ee-2Dcommunity&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=ApVwDI0Z0asEVeTGymKKFxSeOkwzv61nBjTv9HPLyQo&s=PirqAgOvt0vhbhCwZ82j2O0sdqeYieAXwF6MG_dPlEw&e=