Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakartaee-platform-dev] Inconsistency on the term "pruned"

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)    

Back to the top