From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Kevin Sutter
Sent: Thursday, May 21, 2020 7:55 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Inconsistency on the term "pruned"
Hi Hussain,
I'm just not sold yet on the real difference. Why do we have to give a release notice for Proposed Optional? Just because something gets marked as Optional, doesn't mean it's
going away anytime soon. It can be left in Optional state for as many releases as required.
The only advantage I see is that by marking something as Proposed Optional, then you're giving the Community a full release to determine whether it should go Optional or not.
But, have there been any cases where this Proposed Optional decision has actually been reversed? I'm assuming that the decision to make something Optional is not taken lightly and there would be plenty of discussion before we would make that final decision
of going Optional.
A counter argument is that it will take a two releases before a technology can be tagged as Optional (if we keep Proposed Optional). Granted, if we start to have a quicker release
cadence for Jakarta EE, then maybe that's not such a big deal. But, if the discussion has started to make a technology Optional, it just seems like we're slowing down the overall process by going through a Proposed Optional state first.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: <Hussain.NM@xxxxxxxxxxxxx>
To: <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 05/20/2020 15:38
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Inconsistency on the term
"pruned"
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Hi Kevin,
The Jakarta EE pruning definition follows what was defined in JDK 6. We can change this definition to keep up with changes
done in JDK9 (JEP277)[1] and JDK11 (JEP320)[2].
Enhanced Deprecation will be equivalent to “Proposed Optional/Optional” which in a sense means is deprecated in the current
release (but is included in Compatible Implementation) and marked for removal in a future release.
The below line needs to change as this conflicts with the new definition of “Pruned”.
No actual removal from the specification occurs, although the feature may be removed from products at the choice of the product vendor.
I would vote to still keep Proposed Optional as a first step towards deprecation.
Jakarta 10 – Proposed Optional
Jakarta 11 – Optional
Jakarta 12 – Pruned
A technology can remain Proposed Optional for one release
A technology can remain Optional for more than one release
A technology can be Pruned after being marked as Optional in at least one release
For Jakarta EE 9 we can make an exception for Enterprise Beans Interoperability for reasons stated in the release plan[3].
[1]
https://openjdk.java.net/jeps/277
[2]https://openjdk.java.net/jeps/320
[3]
https://github.com/eclipse-ee4j/ejb-api/blob/master/4.0-PLAN.adoc#removal-of-support-for-distributed-interoperability
Thanks
Hussain
From:jakartaee-platform-dev-bounces@xxxxxxxxxxx
<jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Kevin Sutter
Sent: Thursday, May 21, 2020 12:16 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Inconsistency on the term "pruned"
A follow on question to this is whether we plan to stick with the current four stages of "requiredness"...
Currently, we identify jakarta ee technologies as Required, Proposed Optional, and Optional (or "pruned" in the old definition). Now that we are introducing Pruning as actually Removing, do we really need all four stages? Or, could we simplify this to Required,
Optional, and Pruned? I'm just not seeing a need for "proposed optional" any longer.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Kevin Sutter/Rochester/IBM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 05/20/2020 13:18
Subject: Re: [EXTERNAL] Re: [jakartaee-platform-dev] Inconsistency on the term "pruned"
I agree, Edwin. I have no idea why the previous definition of "pruned" meaning "optional" was chosen. Must be a long history with Java. To me, if something is "pruned", it's gone...
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Edwin Derks <ederks85@xxxxxxxxx>
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 05/20/2020 12:37
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Inconsistency on the term "pruned"
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Changing the 'Pruned' definitions explicit to 'Optional' or 'Removed' would make it irrefutable and therefore, prevents confusion. I have been wondering myself in a few cases what to make of it.
Edwin
On Wed, 20 May 2020 at 19:15, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
wrote:
Yes we did mean removed.
Rereading the Jakarta EE 8 platform spec to me that section outlines a 2 step process rather than defining Pruned = Optional .
However I’m not wired to be concerned about normative definitions and things so I will leave detailed comments and conclusions to those that are. It was probably me that messed up by writing pruned rather than removed in the release plan in the first place
:)
Steve
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx<jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Kevin Sutter
Sent: 20 May 2020 17:57
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [jakartaee-platform-dev] Inconsistency on the term "pruned"
Hi,
As I started to update the Platform spec due to our Jakarta
EE 9 Release Plan content, I noticed that the term "pruned" has different meanings depending on the context...
In our Release Plan, we identified the following technologies as "pruned", which in this context meant "removed from the platform":
-
Jakarta Stable API Project Specifications
-
Jakarta XML Registries
-
Jakarta XML RPC
-
Jakarta Deployment
-
Jakarta Management
-
Support for Distributed Interoperability in the EJB 3.2 Core Specification, Chapter 10
But, if you look at theJakarta
EE 8 Platform Spec, the term "pruned" means to only mark the technology as "optional, but it's still part of the platform" (Section 6.1.3 Pruned Java Technologies):
"Technologies that have been pruned as of Jakarta EE 8 are marked Optional in
Jakarta EE Technologies."
Big difference...
First off, I'm taking the stand that we really did mean "removal" when we declared those technologies as "pruned" in the Jakarta EE 9 Release Plan. We've been driving that way with all of the Specs, APIs, TCKs, and CIs for Jakarta EE 9. Just clarifying that
definition and expectation.
The point of this note is to get agreement on the direction of the Platform spec for these definitions. Here's my proposal. Comments/suggestions welcome.
-
Change Platform spec to use Optional instead of Pruned (in the current spec context).
-
Modify the definition of Pruned to mean Removal.
For the last bullet, we could decide to just drop the term "pruned" and use "removed" instead. But, since we already have used the term "pruned" in the Release Plan, I think it would be more consistent to just alter the definition of "pruned" to mean "removed"
in the Platform Spec.
Of course, we would need a "Note" of some type to indicate this change in terminology.
Thoughts? I'd like to get some general feedback before embarking on this type of change since it could have quite the ripple effect. Thanks!
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx
Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original
message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law,
this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance
on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
