That's was the motivation of evaluating the "bit of both" approach; investigate if multiple CIs can be workable with some trimming.
Between the Wildfly and OpenLiberty Platform CCRs, do we know what optional features were not covered?
-- David Blevins 310-633-3852
Just my two cents
worth on the multiple CI approach... I tried to pursue this option
for Jakarta EE 9.1 (a while back when we didn't know the state of Glassfish...).
It just didn't prove fruitful. Each CI still has to certify
to either the Platform or Web Profile (or Core Profile in Jakarta EE 10).
And, since the optional aspects of Jakarta EE are all part of the
Platform requirement, we still required a CI that certified to the Platform.
And, the only CI that certifies to the Platform and implements all
of the optional features is Glassfish. So, combining multiple CIs
for ratification just didn't pan out. I don't see how this scenario
improves down the line if we continue to allow optional features.
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)From:
Scott
Stark <sstark@xxxxxxxxxx>To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>Date:
06/23/2021
20:56Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Discuss proposed Resolution for eliminating
Optional aspects of SpecificationsSent
by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
I'm just not in favor optional features
in any form. Optional != profile. A profile is a set of requirements that
must be implemented by ALL compatible implementations of that profile.
There is no guessing as to which implementation supports what at a given
profile level.There is no need to worry about too many
profile in my view as it is simply too much work to put one together and
maintain it. It is a given under Jakarta that a vendor can include whatever
they want from legacy to future specifications from Jakarta or elsewhere.
If that is not the case, show the guides/policy that contradicts this.
That is one of the main points of the argument in the document against
optional features of specifications.
On Jun 23, 2021 at 4:44:04 PM, David
Blevins <dblevins@xxxxxxxxxxxxx>
wrote:I'd attend next week's meeting to discuss,
but it looks like it's the alternate 6am time for me.
What do people think about taking a bit of both approaches we've discussed:
allowing multiple CIs within reason; reforms on how we treat optional requirements.
Some concerns I have with either approach and high level ideas on how they
might be addressed.
- Complexity from too many CIs. If we needed 4 or 5 CIs to complete
a vote that is clearly too many. This would be an obvious sign the
specification has gone too far with optional features. A potential
remedy would be to limit the number of CIs to say 2 or 3. Perhaps
2 is fine as standard practice, 3 by exception and not for more than say
two releases in a row. We actually used two CIs for Jakarta EE 9.1
as we had different releases of GlassFish.
- Lack of visibility on support of Optional features. Neither users
nor us have a good idea of how many optional features we have and who implements
them. I think a lot of our issues stem from this; we can't see the
breadth of the problem so the the "right thing" can't happen
organically. A potential proposal is that each spec must keep an
inventory of optional features and each CCR must accurately report which
they do and do not implement. If a spec does not have an inventory
of optional features they are ineligible for a release vote.
- Excessive optional features. If say 10% of your TCK is optional
features, that's ok. If over 50% of your TCK is optional as is the
case for EJB that's clearly too far. There are a few remedies for
this. If a feature has been marked optional but in fact everyone
implements it (EJB 2.x views), then it should not be optional.
If a feature is very very large and needs to become legacy but is widely
supported (CMP), it could become its own spec/profile. Of course
removing unsupported optional features is always a potential remedy.
A potential proposal could be to establish a metric; if more than 20% of
your TCK is optional, you are ineligible for a release vote until you remedy
the situation (using any combination the spec project deems fit).
- Too many profiles. At a certain point there can be too many profiles
and 1) this becomes just another word for optional while 2) potentially
still not capturing/accommodating the potential combination of features
a user needs. Rather than create "legacy" profiles we could
allow vendors to ship specifications above and beyond what is included
in the Platform, Web Profile or Core Profile. Meaning you could have
say a Web Profile + JMS implementation. Large legacy features like
CMP would be split into separate specifications and can be included by
implementations in that way. The corresponding TCKs would still exist,
need to be passed and would have to be maintained by those who chose to
continue supporting/shipping that spec; this ensures the tests don't decay
as we move from Java 8 to 11, or 11 to 17, or refactor our TCK harnesses.
The above are just some high level thoughts and are not my ideas.
I'm attempting a "greatest hits" of all our ideas so if you see
things you've advocated, that's me attempting to include your awesomeness
and blend the best of everything put forward.
For all the "ineligible for a release vote" statements, we could
potentially have a grace period and or the ability to request a one-time
exception or a rule change. All this would be in our JESP.
If we decide exceptions can be made, those would all be written down in
a dedicated document that tracks all exceptions made for all specs, including
if they are one-time or ongoing. We could use that over time to track
if we need to adjust our rules. Things like using two versions of
GlassFish would have been written in our exceptions document and could
be leveraged in conversations like this. We could use it as a data
point to demonstrate even GlassFish is having a hard time meeting the "one
implementation must meet all requirements" rule.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852
On Jun 23, 2021, at 1:12 PM, Kevin Sutter
<sutter@xxxxxxxxxx>
wrote:Scott,We decided at the Spec Committee that
we would start the conversation on the private email first -- to ensure
that we have a consistent, agreed-to, defined approach before sending it
to a wider audience. Based on these email discussions, I'm not sure
we're at that point yet. I know we don't need 100% consensus, but
I think it would be good to ensure that we have a super-majority approval
on the direction. Should we take a quick straw poll of the Spec Committee
members? If we have that super-majority, then we could go ahead with
the wider audience. If not, then maybe we need to iron things out
further via email and/or next week's meeting?---------------------------------------------------Kevin Sutter STSM, Jakarta EE and MicroProfile architect
@ IBMe-mail: sutter@xxxxxxxxxx Twitter: @kwsutterphone: tl-553-3620 (office), 507-253-3620
(office) LinkedIn: https://www.linkedin.com/in/kevinwsutterPart-time schedule: Tue, Wed, Thu (off
on Mon and Fri)From: Scott
Stark <sstark@xxxxxxxxxx>To: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>Date: 06/17/2021
12:43Subject: [EXTERNAL]
Re: [jakarta.ee-spec.committee] Discuss proposed Resolution for eliminating
Optional aspects of SpecificationsSent by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>Also, this is on the private list. I
was going to point to the email for some of our project developers, but
found that it was inaccessible by them (and somehow me as well) when trying
to access https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committeeOn Jun 16, 2021 at 1:59:07 PM, Kevin
Sutter <sutter@xxxxxxxxxx>
wrote:On our Specification Committee call today,
we discussed a proposed Resolution (prepared by Dan and Paul) about eliminating
the use of Optional features in Jakarta EE Specifications. We decided
that we should discuss the Resolution via the private mailing list for
the next seven days (max). At that time, hopefully enough input would
produce a version of the Resolution to post to a wider audience (Spec Project
Leads and/or public Spec Committee mailing lists). Again, hopefully,
we would get enough input from these two mailings to allow for a ballot
on the Resolution at our next Spec Committee meeting on the 30th. First, for background, if you are not
familiar with the back story for this Resolution, please review this document:https://docs.google.com/document/d/1O5MnbQRn8RWkM4BpJth9VqGfhKLBZfFzK_fpIyZ_2vw/edit(BTW, before we externalize that document
to the Spec Project Leads and/or public Spec Committee mailing list, we
should resolve any outstanding comments... Dan,I will leave you in
charge of that activity.)The proposed resolution is just a slightly
re-worded version of option #1 in the referenced document.• DRAFT RESOLUTION: To eliminate marking
any Jakarta EE Specification feature as optional in some future release
of each Jakarta EE Working Group Specification, including and possibly
starting with the Jakarta EE Platform Specification Release 10. All
remaining features would be required.• Clarifying text to the proceeding
resolution: The process would be to mark all optional features in the current
release as “Deprecated” in a new Minor release (Release 9.2), and in
a subsequent Major release (not necessarily the very next Major release)
eliminate the Deprecated feature completely from the Jakarta EE Platform
Specification. Eliminating these Deprecated features is not retroactive
to earlier released specifications, which will continue to exist. As implied,
“Deprecated” will be defined as a way of marking a feature as on the
path to complete elimination from some future release, and it indicates
to the public “this feature is going away”. This two-step
process provides a formal communication mechanism within the specification
itself for the Working Group to signal to the community that a feature
will definitely be removed from a future release. The intent is to mark
current features marked as “Optional” as “Deprecated”, but in the future
even “Required” features could be marked as “Deprecated” should the
Working Group decide to prune little used features from the platform. This
two-step process will take longer but will also give consumers of the platform
a longer runway to plan for and deal with the elimination of the feature
should they wish to consume that future platform release.Comments and suggestions are welcome!
Thanks!---------------------------------------------------Kevin Sutter STSM, Jakarta EE and MicroProfile architect
@ IBMe-mail: sutter@xxxxxxxxxx Twitter: @kwsutterphone: tl-553-3620 (office), 507-253-3620
(office) LinkedIn: https://www.linkedin.com/in/kevinwsutterPart-time schedule: Tue, Wed, Thu (off
on Mon and Fri)_______________________________________________jakarta.ee-spec.committee mailing listjakarta.ee-spec.committee@xxxxxxxxxxxTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee_______________________________________________jakarta.ee-spec.committee mailing listjakarta.ee-spec.committee@xxxxxxxxxxxTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee_______________________________________________jakarta.ee-spec.committee mailing listjakarta.ee-spec.committee@xxxxxxxxxxxTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________ jakarta.ee-spec.committee mailing list jakarta.ee-spec.committee@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
