[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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/kevinwsutterFrom:
<Hussain.NM@xxxxxxxxxxxxx>To:
<jakartaee-platform-dev@xxxxxxxxxxx>Date:
05/20/2020
15:38Subject:
[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