Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Proposed revision for resolution for eliminating Optional aspects of Specifications
So I agree with points 1, 2 and the first part of 3.

What I'm not in agreement with is anything special being done by implementers. As is being discussed in a separate thread is that what optional features are being implemented should be manifest in the output of the TCK results.


On Wed, Jul 14, 2021 at 1:03 PM Paul Buck <paul.buck@xxxxxxxxxxxxxxxxxxxxxx> wrote:


As noted in the draft minutes from our Specification Committee meeting today (07/14),  there was a candidate consensus on a pragmatic first step towards "eliminating" optional aspects from specifications, we agreed we would collaborate further on the proposal in the mailing list. For Jakarta EE 10...
  • No new optional features in the Platform or Web Profile in Jakarta EE 10
  • Remove these 2 optional features: Entity Beans and Embeddable EJB Container
  • Spec projects be clearer on what features are optional and implementers clear on which optional features they implement
    • Guidance on how to document to be provided to projects from the Specification Committee
Please add your comments, I think we need to wrap this one up by our next meeting on 07/30 if we are going to impact Jakarta EE10.

Thanks ... Paul


On Wed, Jul 14, 2021 at 11:21 AM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
We can discuss on today's call (I'll be attending).  I'm on board with the concept of marking the CMP/BMP API as deprecated and treating it as discussed.  I don't view the Embedded EJB API as deprecated or legacy, but would support finding some way to essentially have it not be a blocker for platform releases.

In case the word "remove" comes out of my mouth and people are confused, I've been clear I do support removing, just not blindly removing everything as blanket rule.

On Jun 23, 2021, at 2:44 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

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.

Whatever we call this action we take, the primary concern for me is that if some servers will still ship a feature and users will still use it, there must be tests that are maintained and passed by those who implement it.

-- 
David Blevins
310-633-3852

On Jul 13, 2021, at 8:23 PM, Daniel Bandera <bandera@xxxxxxxxxx> wrote:

To all:

I am actually very surprised at the energy and input on this topic!  I thought it would be totally obvious to our Jakarta EE Working Group that having one and only one compatible implementation (Eclipse Glassfish) being the obstacle to finalizing Jakarta EE Specifications would be an anathema to our community to achieving our collective progress.  Apparently there is at least some controversy over that very basic premise.

Before I begin with my potential revised proposal, here is some discussion from our e-mail note thread and minutes I think are relevant:

    -----------------------
    Minutes:
    [06/30] Dan has reviewed the discussion thread on the mailing list and proposed that the resolution be redrafted to reflect the input. Key objective is to allow for other (besides Glassfish) CI to fully implement the Platform Specification and over time eliminate optional features.
    Scott mentioned that being dependent on one and only one CI creates potentially undue exposure to the releases of Jakarta EE. Objective is to increase the pool of CIs that could be a ratified final CIs.
    Dan asked that an investigation be done to determine which optional features if dropped, would make it possible for other CIs (besides Glassfish) to be a ratified final CIs.
    Question: Does the Web Profile have any optional features? On the call the assessment was No.
    [06/30] Request to non-Glassfish open source Jakarta EE Platform implementations (i.e., WildFly & OpenLiberty) - what is the set of features that are optional and are not implemented in the platform?
    -----------------------
    e-mail:
    Kevin Sutter: I agree -- we would have to (re)define what "optional" means in the Platform Spec.  I was going off of our current definition.  I wonder if we would have to use stronger terminology like maybe "deprecated".  Deprecated features are not portable and not used for ratification.

    This approach would also get us closer to actually removing them from the Spec sometime in the future since they are marked "deprecated".
    -----------------------
To the best of my knowledge (and I am certainly no expert here), if we somehow eliminated Entity Beans and the Embeddable EJB Container specifications from the full platform specifications, both WildFly and Open Liberty would qualify as compatible implementations enabling the finalizing of Jakarta EE Platform Specifications, thus increasing the potential implementations from 1 to 3 that could qualify to help us finalize specifications.

Although this is not in the form of a resolution we could vote on, in straightforward terms, I proposed we define "Deprecated" formally and its meaning in a revised Jakarta EE Specification Process (JESP), mark Entity Beans and the Embeddable EJB Container, as Deprecated immediately, and mandate that Compatible Implementations need not implement Deprecated features to qualify for finalizing Jakarta EE Specifications.

I still believe and support eliminating "optional" features is essential over time, and I certainly would not allow any new additions to the platform to have optional features.

Best regards,
Dan

Dan Bandera
(512) 286-5228
Program Director, Blockchain, Istio, Java technologies, Node.js
IBM Open Technologies, Austin, Texas;          OSGi Laureate;
Interim Chair Eclipse OSGi Working Group Steering 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

Back to the top