-1
I think Kevin counted me as a -1 based on my comments on vote 2, so making it formal. I am ok with these APIs being optional, but I believe that they should be moved to the Jakarta namespace because that is what big bang requires. While today we cannot see obvious reasons to evolve these APIs they are still commonly used and that means to me that a future need to evolve is non-zero. We are moving EJB despite the fact a significant group of people think it is legacy and the evolution should push it out of the platform in favour of a CDI based approach and I think SOAP use is more common that IIOP.
Alasdair
> On Dec 9, 2019, at 8:36 AM, Kevin Sutter <
sutter@xxxxxxxxxx> wrote:
>
> +1
>
>
> ---------------------------------------------------
> 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>
>
>
> From: "Kevin Sutter" <
sutter@xxxxxxxxxx>
> To: "jakartaee-platform developer discussions" <
jakartaee-platform-dev@xxxxxxxxxxx>
> Date: 12/04/2019 17:33
> Subject: [EXTERNAL] [jakartaee-platform-dev] NEW VOTE 3: Optional Specs for the javax namespace
> Sent by:
jakartaee-platform-dev-bounces@xxxxxxxxxxx>
>
>
> Preamble:
https://www.eclipse.org/lists/jakartaee-platform-dev/msg01180.html>
> Please vote +1/0/-1 on the following. Any non +1 vote, please provide reasoning in your reply. Thank you!
>
> Mark Optional (Leave in javax namespace) - Vote
> • Jakarta XML Binding 2.3 JSR 222
> • Jakarta XML Web Services 2.3 JSR 224
> • Jakarta Web Services Metadata 2.1 JSR 181
> • Jakarta SOAP with Attachments 1.4 JSR 67
>
> You need to understand and vote on the Jakarta Activation Vote 2 before voting here. If Jakarta Activation is voted to move to the jakarta namespace, then these Specs can not be optional due to the dependencies. Check out this tool from Tomitribe:
https://www.tomitribe.com/jakarta/ns/poll/vote>
> These are four of the APIs that were recently dropped from Java SE 11 per JEP 320 (another one was Activation and that's the subject of a separate Vote 2). There was a lot of discussion about whether these should be left out or added back in, and whether the namespace should be updated or not. We are proposing that we leave all four of these Specifications/APIs in the javax namespace and clarify their usage as Optional in the Jakarta EE 9 Platform. This should be the minimal effort option to lower the bar for new implementations.
>
> Note: This assumes that all of the existing Specification PRs for these technologies are properly brought under the EE4J umbrella. We discussed these at the Spec Committee call today and we are well aware that we need to move on these and get them approved.
> •
https://github.com/jakartaee/specifications/pulls?q=is%3Apr+is%3Aopen+label%3Ajavase>
> ---------------------------------------------------
> 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 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 