[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE 9
|
I think this was what Scott proposed as well. I think it makes sense.
Basically update its namespace and leave it at that state.
Emily
If the consensus is that JAX-WS shouldn't be a required spec for JakartaEE 9, is there a problem to evolve JAX-WS as an optional spec? We can migrate JAX-WS to the jakarta namespace and still keep it outside of JakartaEE umbrella, am I wrong?
I think that way all the legacy solutions could adopt JakartaEE 9 and still support their current users/customers with JAX-WS, while at the same time new JakartaEE implementations wouldn't need to support it.
Ondro
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
