Re: [jakarta.ee-spec.committee] Discuss proposed Resolution for eliminat

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Possibly define a
profile that maps to your optional aspects of the messaging spec?  Maybe
call it "legacy profile".  The CI used for ratification
of Messaging would still need to provide all features of Messaging, including
the Legacy profile.  Would the Platform require the Messaging Legacy
profile?  Lots of different ways to slice and dice this.

The other thing
to consider is just dropping these optional pieces from the Messaging spec
going forward.  Implementations can still implement these old optional
pieces, but they are no longer defined in the current spec.  Since
we have everything all defined under the Jakarta umbrella, dropping some
features is doable.  When we were first considering dropping some
of these optional features back in Jakarta EE 9 (ie. Entity Beans), it
would have been very difficult due to the mix-and-match of the two namespaces.
 But, now that everything has moved to the jakarta namespace, dropping
some of the old optional features from the current specs is a more doable
operation.

We really need
to get away from depending on Glassfish as being the only "complete"
implementation of all required and optional features of Jakarta EE.  This
is the proposal that has been discussed at the last several Spec Committee
meetings.  If you have other ideas on how to resolve this issue, we're
all ears.  Thanks!

(BTW, Ed brought
up these Messaging discussions and the Optional pieces being discussed.
 This is why we need to expand the audience for this discussion.  But,
we need to ensure that the Spec Committee is on the same page first.)

---------------------------------------------------
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/16/2021
15:01
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>

---

Today we had our first meeting of the
Jakarta Messaging project and discussed making several aspects optional.
 Specifically some of the messaging guarantees such as durable topics,
explicit acknowledgement, message ordering and transactions.  These
are already options for users, but currently implementations must support
them even if the user does not use them.

The motivation for allowing them to also
be optional to implementors is to encourage more implementations; specifically
from cloud providers and to make room for Kafka-like implementations.  There
was explicit discussion that the guarantees planned to be optional are
still valid, not flawed or legacy, critically needed by some, not planned
be removed and that new versions of the API such as the proposed annotation
based API will cover and account for these optional features.  The
spirit we discussed for the API design is that anything optional would
effectively be off by default and could be turned on via annotations/api
calls by users who need them on implementations that support them.

How would this proposal map to our scenario
we the planned use of optional is not because of legacy and simply to make
room for more implementations?


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852

On Jun 16, 2021, at 12:27 PM, Kevin Sutter
<sutter@xxxxxxxxxx>
wrote:

David,
Short answer -- to avoid always being dependent on Glassfish as the Compatible
Implementation.
Longer answer -- read through the referenced document.

---------------------------------------------------
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/16/2021
14:08
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>

---

What is the issue with optional features that we're trying to avoid?


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

On Jun 16, 2021, at 11:59 AM, 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