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
Questions and observations...
  • Do these bullets only apply to the Platform and Web Profile Specifications?  For example, are we going to declare "no new optional features" for all Jakarta EE Specifications?  Or, just the Platform and Web Profile?
  • I'd like to clarify what "remove" means in the second bullet.  The current EFSP states that all optional features need to be implemented by the ratifying compatible implementation.  So, are we introducing the idea of "deprecated" features that are not required for ratification?  Or, what does "remove" mean?
  • I think we have to be careful with these types of statements:
     "- a Spec (which can be a Platform, Profile, or plain Spec) to consume/require just a subset of another spec.  I.e. Platform consumes EJB without CMP/BMP and Embedded EJB Container"

    We've stated in the past that subsetting a Specification can not be done by the consumer.  As long as the subsetting is defined by the producer (required, optional, deprecated, etc), then the consumer can determine which pieces they will consume.  For our particular case with the EJB features, I think we're fine since both Entity Beans and the Embeddable EJB Container are optional features and the Platform is now going to indicate these are not required for ratifying implementations.  I just don't want to open the door for the consumer to define what's required and what's optional.
  • Getting the Specs and TCKs more consistent and more clear on what's required and what's optional is a great long-term goal.  But, it's not going to happen overnight (ie. Jakarta EE 10).  It will be a work in progress, much like dividing up the Platform TCK into its respective components.


---------------------------------------------------
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:        07/14/2021 15:58
Subject:        [EXTERNAL] Re: [jakarta.ee-spec.committee] Proposed revision for resolution for eliminating Optional aspects of Specifications
Sent by:        "jakarta.ee-spec.committee" <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>



Thanks, Paul.

On Jul 14, 2021, at 11:02 AM, Paul Buck <paul.buck@xxxxxxxxxxxxxxxxxxxxxx> wrote:
  • 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
Agreed.  It seems these two are actions that can be taken by the Platform project and don't need reforms by the Spec Committee.  I'd be great if others could weight in on that.

If there is an action item for the Spec Committee it might be to clarify that it is ok for:

 - a Spec (which can be a Platform, Profile, or plain Spec) to consume/require just a subset of another spec.  I.e. Platform consumes EJB without CMP/BMP and Embedded EJB Container
 - a implementation of a Spec (which can be a Platform, Profile, or plain Spec) to include additional specs (and their associated optional features) in their distribution

We seem to have this mutual understanding, but I'm not sure it's written down.
  • 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

This would definitely be an action item for the Spec Committee.  We'd need to decide if it's a recommendation or requirement and what the format should be.  Given the current state of imperfect lineup between specs and TCKs on what is viewed as optional, we'd probably have to live with a certain amount of imperfection for a while.


-David

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
http://twitter.com/dblevins
http://www.tomitribe.com
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
_______________________________________________
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