[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] NEW VOTE 3: Optional Specs for
|
Hi Mohamed,All four of these
Specifications (JAXB, JAX-WS, SOAP, and WS Metadata) are already in the
works to move them to the respective EE4J projects. You can see the
PRs that are in flight via this query:https://github.com/jakartaee/specifications/pulls?q=is%3Apr+is%3Aopen+label%3AjavaseThe ball is in
the Spec Committee's court to complete the preliminary approvals and then
post them for official ballots. Once these are complete, then the
initial move to the Jakarta/EE4J projects will be complete. There
will be Maven artifacts under the jakarta artifact namespace, but the packages
will still be using the javax namespace. Please feel free to review
these and provide comments if you see anything out of place. But,
the work was pretty much done by Lukas already.If these APIs
would need to evolve in the future, then the APIs have to move to the jakarta
namespace. Evolving these APIs in the javax namespace is not doable.Hope this helps
with the understanding.
---------------------------------------------------
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/kevinwsutterFrom:
"Mohamed
M. El-Beltagy" <melbeltagy@xxxxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>Date:
12/09/2019
13:50Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] NEW VOTE 3: Optional Specs forSent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
I agree that jaxb is widely used and
will be used, along with soap, for quite sometime.But let's differentiate between jaxb
and soap progress as part of Jakarta EE or as a stand alone specification.This vote is not against them evolving.
I am pretty sure that Kevin tried to clarify this on many replies already.So, the best case scenario from my perspective
is to have them optional without moving to Jakarta namespace. This is from
Jakarta ee perspective.And also, meanwhile, we would align a
big bang migration for those two technologies in parallel outside of the
Jakarta ee project.1. Basically, it allows new vendors to
ditch them2. Allows existing implementations to
migrate and support new versions whenever they like.3. Allows the libraries to evolve in
synch with Jakarta ee. Which can be easily added as a support through implementations
later on.If that is OK from legal side, which
as far as I understand is yes, then I would like to join the efforts to
migrate them as standalone standards.Kevin, would that be an option?I know you have replied to this before.But just let's have a clear yes/no answer
(hopefully for the last time).Best regards,
Mohamed Elbeltagy
Sent from Yahoo Mail on AndroidOn
Mon, Dec 9, 2019 at 8:12 PM, Alasdair Nottingham<alasdair.nottingham@xxxxxxxxx>
wrote:-1
I think Kevin counted me as a -1 based on my comments on vote 2, so making
it formal. I am ok with these APIs being optional, but I believe that they
should be moved to the Jakarta namespace because that is what big
bang requires. While today we cannot see obvious reasons to evolve these
APIs they are still commonly used and that means to me that a future need
to evolve is non-zero. We are moving EJB despite the fact a significant
group of people think it is legacy and the evolution should push it out
of the platform in favour of a CDI based approach and I think SOAP use
is more common that IIOP.
Alasdair
> On Dec 9, 2019, at 8:36 AM, Kevin Sutter <sutter@xxxxxxxxxx>
wrote:
>
> +1
>
>
> ---------------------------------------------------
> 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: "Kevin Sutter" <sutter@xxxxxxxxxx>
> To: "jakartaee-platform developer
discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
> Date: 12/04/2019 17:33
> Subject: [EXTERNAL] [jakartaee-platform-dev]
NEW VOTE 3: Optional Specs for the javax namespace
> Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
>
>
>
> 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
>
>
>
> _______________________________________________
> 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
