[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec.committee] [External] : Re: Discuss proposed Resolution for eliminating Optional aspects of Specifications
|
I did some review of the Platform Spec. and also the TCK user
guide. To me, the work necessary to accomplish the goal looks like
a rather heavy lift. I wonder if we might consider taking a more
measured approach and declare that Optional features are to be
discouraged and over time eliminated. We may be able to remove
optional features from the Platform spec., but even that will
likely be a fair amount of work.
I believe, the Platform spec currently declares many features
optional -- and also in some cases elevates component spec
optional features to required (at lest in Servlet and RESTful Web
Services).
I would certainly appreciate other eyeballs on this list. The
Platform lists the following as optional:
- RMI-IIOP
- Java IDL
- XML Web Services
- Enterprise Web Services
- Web Services Metadata
- XML Binding
- SOAP with Attachments
- OMG interoperability protocols
- Enterprise Bean CMP
- Enterprise Bean BMP
- Enterprise Beans 2.x API group
- Enterprise Bean Query Language
Additionally, the following probably need to be reviewed and
possibly revised:
- Probably we need to remove the optional aspects of JPMS
support (Sec. 8.2) -- rewrite as requirements.
- Probably all possibly dangling refs. to Deployment API need to
be removed (revise Section 8.5)
- Probably need to reword Servlet so optional features in the
component Spec., which are described as requirements for the
Platform are not interpreted as optional (and deprecated).
(Section 6.4, Servlet 5.0 Requirements)
- Probably need to review and possibly rewrite some of the
Messaging requirements (Section 6.7)
- Probably need to review and possibly rewrite fourth paragraph
in 6.1.2 RESTful Web Services 3.0 requirements (optional
container managed facilities are elevated to required for
Platform use)
- For non-required Specs. that an implementation chooses to
include, we will need a way to define requirements for those
component to be included in a controlling document --e.g. if an
implementation wants to continue to support XML Web Services --
it may do so, and those component implementations must pass
their associated component TCK -- The Platform (or some
controlling document) should be explicit that it is not
allowable to claim support for a component API, but not pass
that component's TCK.
If we are going to deal with component specifications, we may
need to get into some details that may not be so obvious -- For
example, with CDI -- when run on a Platform Implementation the
number of tests for PASS result is 1794. For web profile a
successful result is 1665. What does that difference say about
features and/or tests required or optional? Further, if a
web-profile only Platform revision were to be contemplated, we
should address how those untested features are validated (or if
they are validated))
As part of this overall goal, I believe we will also need to
revise:
- In the Platform Spec
- 6.1.3. Optional Jakarta Technologies
- Reduce or eliminate 9.6 Optional Features for Jakarta EE
Profiles
- Update 2.7.1 HTTP
- 2.7.13 Jakarta Connectors -- revise text in last bullet --
the contract interface must be supported (users are free to
use or ignore this feature) -- I think. This revision pattern
is repeated in many places -- the implementation must provide
for the indicated feature. The user is free to use, or not.
- The API list in 6.1.1.1 Java SE Enterprise Technologies --
should be revised with Jakarta Names where the specs. have
been contributed to Eclipse. (Perhaps this is not actually
related to the subject at hand)
- In the TCK User Guide
- Where needed, TCK rules and instructions will need to be
revised -- javaee_optional, ejb_1x_optional, ejb_2x_optional
(Platform TCK User Guide Table 7.1, Keyword to Technology
Mappings for Full Profile Optional)
- If needed, rework TCK user guide text to reflect profile
functional sets (javaee_web_profile_option,
connector_web_profile, jms_web_profile, et (Platform
TCK User Guide Table 7.2, Keyword to Technology Mappings for
Web Profile Optional)
- ibid, Table 7.3, TCK Keywords for Optional Jakarta
Enterprise Beans Lite Components
- Review the definition of Operating Mode to determine if that
can remain part of the Specifications
I'm not against the general goal -- We want more compatible
implementations to be suitable for Spec. ratification. I just
think that a "hard no" to optional features may be be more
difficult than it might seem.
If the legacy Enterprise Beans features are the only feature that
is reasonably preventing a large suitably large class of
alternative compatible implementations for ratification -- In
addition to discouraging Optional features, what about eliminating
those legacy Jakarta Enterprise Bean from EE 10? Do we think we
can address everything listed above and get EE 10 completed on
it's current schedule?
-- Ed
On 6/24/2021 11:29 AM, Kevin Sutter
wrote:
Entity Beans
(BMP
and CMP) :-)
---------------------------------------------------
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:
David
Blevins <dblevins@xxxxxxxxxxxxx>
To:
Jakarta
specification committee
<jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:
06/24/2021
13:04
Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Discuss proposed Resolution for
eliminating
Optional aspects of Specifications
Sent
by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
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
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852
On Jun 24, 2021, at 6:50 AM, Kevin
Sutter
<sutter@xxxxxxxxxx>
wrote:
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:56
Subject: [EXTERNAL]
Re: [jakarta.ee-spec.committee] Discuss proposed Resolution for
eliminating
Optional aspects of Specifications
Sent 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 @ 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/17/2021 12:43
Subject: [EXTERNAL] Re: [jakarta.ee-spec.committee]
Discuss proposed Resolution for eliminating Optional aspects of
Specifications
Sent 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.committee
On 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 @ 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)
_______________________________________________
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@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@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@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://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee__;!!ACWV5N9M2RV99hQ!aTcstSr96VkHUVBFmJt-IF3-0k3Skb1nFBQSsk91jiL5oH6zAvKDCsGS4ITDOu8$