[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] Inconsistency on the term "pruned"
|
Absolutely agree
with your statements, Gurkan. We need this ability to actually remove
old, stable technologies. Thanks for the input.
---------------------------------------------------
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:
Gurkan
Erdogdu <cgurkanerdogdu@xxxxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>Date:
05/21/2020
06:13Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Inconsistency on the term "pruned"Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
HiI have +1 VOTE to Prune = Remove.
Especially for those who want to develop
a new Jakarta EE certified server, we should make this step easier and
removing all old and pruned technologies from both spec and implementations.Regards.GurkanOn Thu, May 21, 2020 at 2:01 PM Emily
Jiang <emijiang6@xxxxxxxxxxxxxx>
wrote:From my understanding, "Proposed
Optional" means "Required" with some warning, as it might
go Optional in the next release. I guess some feedback gathering need to
happen for discussing whether to make Proposed Optional to Optinal in the
upcoming release or not. I understand the proposed optional is used in
JDK, as it has 6-month release candance, which gives customers 6 months
to prepare. Maybe keep 4 phases for now, after a couple of Jakarta EE releases,
we will figure it out how soon we can or want to release Jakarta EE. If
we do it every 6 months, maybe we can utilise the stage of Proposed Optional.
Otherwise, we can get us to 3 phases.EmilyOn Thu, May 21, 2020 at 1:30 AM kzr@xxxxxxxxxxx<kzr@xxxxxxxxxxx>
wrote:There is a big difference
between Required and Optional.Optional means that
a vendor does not need to implement the spec.That is, the vendor
product removes the implementation of the spec. Proposed Optional has
the meaning to mitigate this big impact.Proposed Optional gives
the customers the time to prepare consideringwhether they should
keep using this spec or not.And they can also negotiate
the vendors to ask keep their products including this spec. If there is no Proposed
Optional state, the customer cannot have such a time. -Kenji Kazumura 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
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
Thanks
Emily
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
-- Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev