Hi,
I've been trying to keep up with this thread, and potential options that people have expressed about pruning, deleting, deprecating and making optional. I've replied to Kevin's email as that has the suggestion to remove JAX-WS (hope I read that right, I apologize if not). JAX-WS is something that appears to still be in use, and may be something TomEE would still look to support, and that triggered a few questions.
* Vendors could still provide support for the components that have been removed? (I'm assuming this is a yes based on my reading)
* Would those specs still use the javax. package? (again, I'm assuming a yes)
* For specs like CMP beans for example, would we produce a spec jar that still had the CMP specific stuff with a javax. package, and the other enterprise bean classes and interfaces move to jakarta.?
* If removed specs wanted to evolve outside Jakarta EE in the future, would they still sit under javax., or would they need to move to another package if that evolution happened?
* If those specs did evolve (I know this may well be unlikely), could different app servers targeting the same Jakarta EE version potentially target different versions of these removed specs?
* If, say, JAX-WS is removed, for example, but vendors still wished to support it, is there any vision for what that might look like? For example, would an end user be able to expect an EJB 3.x session bean exposed as a web service to still work, or would that be entirely up to individual vendors? If EJB session beans are kept and JAX-WS removed, would we expect any EJBs annotated with JAX-WS annotations to fail at deploy time?
* What's the overhead to keeping these specs for now, and planning to prune after the package rename has taken place?
I appreciate all the discussion on this - thank you.
+1
I know that the
Enterprise Web Services specification is kind of tied to the JAXB/JAX-WS
discussion in the Add vote. But, since I would like to see none of
this in Jakarta EE 9, I'm voting a +1 for all of this pruning on the hopes
that it might help influence the Add Specification discussion.
---------------------------------------------------
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:
"Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
11/17/2019
10:56
Subject:
[EXTERNAL]
[jakartaee-platform-dev] VOTE: Specifications to Prune in Jakarta
EE 9
Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
See
previous email for context.
All
committers please vote on this proposal for specifications to be pruned
from the Jakarta EE 9 platform specifications.
The
following specifications will be *removed* from Jakarta EE 9 Full profile
specification.
-
Jakarta XML Registries JSR 93
-
Jakarta XML RPC JSR 101
-
Jakarta Deployment JSR 88
-
Jakarta Management JSR 77 note this was not optional or deprecated in Java
EE 8
-
Jakarta Enterprise Bean entity beans – Note this is old style CMP and
BMP entity beans NOT JPA Entities
-
Jakarta Enterprise Bean interoperability
-
Jakarta Enterprise Bean 2.x and 1.x client view
-
Jakarta Enterprise Web Services JSR 109
Please
vote by reply with +1, 0, -1 in accordance with the Eclipse Development
Process.
Thanks
Steve_______________________________________________
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
_______________________________________________
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