Kevin,
> Could this last item just be included with the next vote? I don't know what it means to vote on removing EJB Entity Beans if we don't clarify the > extent of this removal.
Yes.
> Note: No new profiles are being considered for Jakarta EE 9. So, anything like a "legacy profile" would be post Jakarta EE 9. And, thus at this > point, this c-3 vote is not much different
from c-1 -- leave them where they are now and we'll figure out a proper location post Jakarta EE 9.
I think we need to consider both how and when we should handle these APIs.
For example, the vote may be different between following two options.
- do not include in Jakarta EE 9, and will never include in any profiles
- do not include in Jakarta EE 9, but will include in some profiles
-Kenji Kazumura
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx]
On Behalf Of Kevin Sutter
Sent: Monday, December 2, 2019 11:47 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [proposal] new votes
Thanks, Kenji! Steve and I have been discussing something very similar. A few comments below...
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
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-bounces@xxxxxxxxxxx wrote on 12/02/2019 01:17:07:
> From: "kzr@xxxxxxxxxxx" <kzr@xxxxxxxxxxx>
>
> According the current discussions,
> I propose the following four votes instead of current "Add" and "Prue" votes.
> Any comments?
>
>
> (a) Remove old specs from Jakarta EE 9.
> - Jakarta XML Registries JSR 93
> - Jakarta XML RPC JSR 101
> - Jakarta Deployment JSR 88
> - Jakarta Management JSR 77
> - Jakarta Enterprise Bean entity beans
Could this last item just be included with the next vote? I don't know what it means to vote on removing EJB Entity Beans if we don't clarify the extent of this removal.
>
> VOTE [+1, 0, -1]
>
> (b) remove EJB 3.2 optional feature specification (not EJB 3.2 core spec)
> - Jakarta Enterprise Bean interoperability
> - Jakarta Enterprise Bean 2.x and 1.x client view
To be very clear, I think this vote should be to remove all optional features documented in the EJB 3.2 Optional Feature Specification (and nothing from the EJB 3.2 Core spec):
• EJB 2.1 Entity Bean Component Contract for Container-Managed Persistence
• EJB 2.1 Entity Bean Component Contract for Bean-Managed Persistence
• EJB 1.1 Entity Bean Component Contract for Container-Managed Persistence
• Client View of an Entity Bean
• EJB QL: Query Language for Container-Managed Persistence Query Methods
• JAX-RPC Based Web Service Endpoints
• JAX-RPC Web Service Client View.
>
> VOTE [+1, 0, -1]
>
> (c) JAX-WS and related specifications
> - Jakarta Enterprise Web Services JSR 109
> - JAX-WS(Java SE) JSR224
> - JAX-B(Java SE) JSR222
>
> (c-1) do not include them in Jakarta EE 9
> (use javax name space)
> VOTE [+1, 0, -1]
>
> (c-2) include them in Jakarta EE 9
> (use jakarta name space)
> VOTE [+1, 0, -1]
>
> (c-3) do not include them in Jakarta EE 9,
> but include them in Jakarta EE spec projects,
> and exist in only a separate profile such as "legacy profile"
> (use javax name space)
Note: No new profiles are being considered for Jakarta EE 9. So, anything like a "legacy profile" would be post Jakarta EE 9. And, thus at this point, this c-3 vote is not much different from c-1 --
leave them where they are now and we'll figure out a proper location post Jakarta EE 9.
> VOTE [+1, 0, -1]
>
>
> (d) Remove EJB Embeddable Container from Jakarta EE 9
>
> VOTE [+1, 0, -1]
>
> -Kenji Kazumura
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>
