Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE 9

["Kevin Sutter" <sutter@xxxxxxxxxx>]

>  We
can do a full package rename to those APIs outside of Jakarta EE, don't
we?

Any renaming of
the remaining packages would need to be done within the Eclipse environment.
 But, they wouldn't necessary have to be part of the Jakarta EE Platform.
 But, this would be an edge case sometime in the future.

---------------------------------------------------
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:
       "Mohamed
M. El-Beltagy" <melbeltagy@xxxxxxxxx>
To:
       jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
       11/25/2019
12:46
Subject:
       [EXTERNAL]
Re: [jakartaee-platform-dev] VOTE: Specifications to add in    
   Jakarta        EE 9
Sent
by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx

---

Kevin,

Many thanks
for taking the time and effort withstanding my confusion around different
JSRs and hence my emails and taking the time to clarify things up.
Yes. Now I
do understand that we have the following:

1. JSR 109
=> Implementing Enterprise Web Services        
                     
  => Just an umbrella spec to contain all specs related to SOAP
and REST.
2. JSR 224 => JavaTM API for XML-Based Web Services (JAX-WS) 2.0  
  => JAX-WS (or, as some call, SOAP)
3. JSR 67  => JavaTM APIs for XML Messaging      
                     
              => SAAJ (or, as some
call, SOAP Attachments)
4. JSR 181 => Web Services Metadata for the JavaTM Platform

And that JSR
224 and 67 were part of Java SE (prior to Java 11). Same applies to JAXB.
In that case,
and since JAX-WS (SOAP) is considered legacy, as you highlighted earlier,
it makes perfect sense to not re-include it.
Let these
APIs evolve on their own pace, if required.

We can do
a full package rename to those APIs outside of Jakarta EE, don't we?

Best regards,
Mohamed Elbeltagy


On
Monday, November 25, 2019, 4:47:12 PM GMT+2, Kevin Sutter <sutter@xxxxxxxxxx>
wrote: 


Mohamed,
We can't deprecate something that doesn't exist...  :-)  The
Specifications/APIs that are being proposed to be added were actually part
of Java SE.  Years ago, these technologies were deemed pervasive and
should move from the Java EE (Enterprise) space to the Java SE space.  The
Platform spec still referenced them, but it was explained that these were
part of the Java SE offering, not Java EE.

But, now as of Java 11, these "Enterprise" APIs were dropped
from Java SE.  So, they are in limbo.  If there is desire to
evolve these APIs in the Java EE space, then they would need to be re-added
to the Java EE space.  That is what we are discussing -- whether to
re-add these technologies into Java EE that used to be part of Java SE.

If we leave them where they are, then they will stay in the javax namespace.
 As a reminder, any evolving of the javax APIs has to be done in a
separate namespace (ie. jakarta).

---------------------------------------------------
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:        "Mohamed
M. El-Beltagy" <melbeltagy@xxxxxxxxx>
To:        jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:        11/23/2019
12:50
Subject:        [EXTERNAL]
Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE
9
Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx

---

Why not deprecate its usage in Jakarta EE.

It would be giving users some period to refactor out of it.
Same as what happened with Entity Beans in favor to JPA (at Java EE 6 release).

Also, that allows individual specs to evolve (if required) without impacting
Jakarta EE.

Best regards,
Mohamed Elbeltagy


On Saturday, November 23, 2019, 9:14:07 AM GMT+2, Edwin Derks <ederks85@xxxxxxxxx>
wrote: 


Or maybe put this “optional” in a separate new profile?

Edwin

On Sat, 23 Nov 2019 at 00:35, Bill Shannon <bill.shannon@xxxxxxxxxx>
wrote:
How is "optional" different from "not added"?

What can I do with an optional spec vs. a spec that exists but is not included
in Jakarta EE?

Steve Millidge (Payara) wrote on 11/22/19 10:36 AM:
Perhaps we need to kick off a vote on JAX-WS, it could be optional? Adding
it as optional will still mean the project will have to do a release so
will likely impact timelines.
 
 
From:jakartaee-platform-dev-bounces@xxxxxxxxxxx<jakartaee-platform-dev-bounces@xxxxxxxxxxx>On
Behalf Of Kevin Sutter
Sent: 21 November 2019 14:08
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] VOTE: Specifications to add in
Jakarta EE 9
 
Scott,
This is exactly what we're struggling with in our discussions at IBM.  We
have many existing JAX-WS customers.  So, if we move JAXB to the jakarta
namespace, but not JAX-WS, then we will have two different JAXB APIs to
support.  But, we also recognize that JAX-WS is a legacy technology
that probably shouldn't be part of the long term plans for Jakarta.

---------------------------------------------------
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:        Scott
Stark <starksm64@xxxxxxxxx>
To:        jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:        11/21/2019
03:04
Subject:        [EXTERNAL]
Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE
9
Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx

---

There still could be an update of JAX-WS to match the JAXB package changes without JAX-WS being an official part of EE 9 I suppose. JAX-WS is certainly a legacy tech that I would not expect customers to want to have to update their use for JAXB changes, but it could be beneficial to porting layers to have a JAX-WS release that allows for a runtime to make use of a single EE 9 based JAXB implementation.


> On Nov 20, 2019, at 1:58 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
>
> If JAX-WS is not in EE 9, and a product that implements EE 9 wants to also support JAX-WS, that that product would need to satisfy the dependency on JAXB.  It could provide both javax.xml.bind and jakarta.xml.bind APIs, or it could use one of the backwards compatibility approaches to map javax.axml.bind APIs to jakarta.xml.bind APIs.
>
> But yes, having two implementations would make it hard to share binding classes.
>
> Andy McCright wrote on 11/20/19 11:19 AM:
>> Would this also require adding the JAX-WS APIs to the EE9 spec?
>>
>> The JAX-WS APIs that have been removed from the JDK currently have a dependency on JAXB.  If we evolve JAXB in EE9 (or just rename the packages), then we have some specs (like JAX-RS and maybe JPA, etc.) that depend on the jakarta.xml.bind.* packages while others (JAX-WS) that would depend on the javax.xml.bind.* packages. That would certainly make it difficult for EE9 applications to use both a JAX-RS and JAX-WS frontend that shares the same XML binding classes.
>>
>> Thanks, Andy

_______________________________________________
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

_______________________________________________
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_______________________________________________
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_______________________________________________
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