| I don't understand this comment: 
  If
        Jakarta Activation is voted to move to the jakarta namespace,
        then these
        Specs can not be optional due to the dependencies.As far as I can tell, none of these specs have any API dependencies
    on Activation, although it's used in the implementation of some of
    them.  Is there something I'm missing?  Why does the package name of
    Activation control whether or not these can be optional? 
 
 
 Kevin Sutter wrote on 12/4/19 3:33 PM:
 
      
      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
 
 |