Re: [jakartaee-platform-dev] NEW VOTE 3: Optional Specs for the javax na

[Mark Struberg <struberg@xxxxxxxxxx>]

-1

Agree with MKarg. Let's minimise user confusion.

Whether those packages will be 'optional' for a Jakarta Server release or not is another story.
But we should move it to a new package.

LieGrue,
strub

> Am 05.12.2019 um 07:17 schrieb Markus KARG <markus@xxxxxxxxxxxxxxx>:
> 
> -1 as my target is a big bang including APIs even never changed again, to keep the confusion for the user lower which package is renamed in which release 
>  
> Von: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] Im Auftrag von Kevin Sutter
> Gesendet: Donnerstag, 5. Dezember 2019 00:33
> An: jakartaee-platform developer discussions
> Betreff: [jakartaee-platform-dev] NEW VOTE 3: Optional Specs for the javax namespace
>  
> 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