$)CThanks,
Markus. I
created the following issue: https://github.com/eclipse-ee4j/jaxrs-api/issues/815to make the JAXB
dependency optional for JAX-RS.
I know we
don't
have a lot of time before we need to report back to the Steering
Committee.
But, if there's enough interest in your community to support
this
issue, then maybe we can adjust this Add vote to only include
Activation?
I've seen some additional -1 votes come in after mine, so there
is
some hesitancy on Adding JAXB to Jakarta. I think the JAXB
dependency
was key to some of the +1 votes (imho).
---------------------------------------------------
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:
"Markus
KARG" <markus@xxxxxxxxxxxxxxx>
To:
"'jakartaee-platform
developer discussions'"
<jakartaee-platform-dev@xxxxxxxxxxx>
Date:
11/27/2019
00:40
Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] VOTE: Specifications to add
in JakartaEE 9
Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Kevin,
JAX-RS
API itself is not deeply related with JAXB, but the spec just
mandates
its support. We could modify the spec to simply make the
support optional,
so JAX-RS vendors would be free to provide their own copy of
the API JAR
instead of relying on Jakarta EE JAR to contain the JAXB
interfaces and
classes. In fact, I feel like there even would be a majority
of JAX-RS
committers actively supporting this idea, as modern
applications rely on
JSON instead of XML, and existing applications will still work
fine once
the JAX-RS vendor decides to still deliver support for JAXB.
But in the
end, we have to do a poll among the JAX-RS committers. Do you
like to open
an issue in our tracker?
-Markus
Von:jakartaee-platform-dev-bounces@xxxxxxxxxxx
[mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Kevin Sutter
Gesendet: Dienstag, 26. November 2019 20:41
An: jakartaee-platform developer discussions
Betreff: Re: [jakartaee-platform-dev] VOTE:
Specifications to add in
JakartaEE 9
Werner,
Let's not mix up the MicroProfile and Jakarta EE spec co-usage
with this
discussion. That aspect of the relationship is being worked.
Any evolution of the JAXB API has to be outside of the javax
namespace.
Whether it's done as part of the Jakarta Platform or as a
separate
EF project, it still would have to be done as part of
Specification Project.
And, this Specification Project would need to be part of a
Working
Group that has accepted the Eclipse Foundation Specification
Process. Right
now, that limits us to the Jakarta EE Working Group. Thus, a
separate
EF project would still be under the EE4J umbrella. Given our
current
constraints.
Markus,
One question I have is how dependent is JAX-RS on JAXB? Or,
could
JAX-RS be modified to remove the dependency on JAXB? For
example,
if the voting for this Add doesn't pass and JAXB is not added
to Jakarta
(integrated or separate), then what impact will that have on
JAX-RS?
---------------------------------------------------
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: Werner
Keil <werner.keil@xxxxxxx>
To: jakartaee-platform
developer discussions
<jakartaee-platform-dev@xxxxxxxxxxx>
Date: 11/26/2019
13:22
Subject: [EXTERNAL]
Re: [jakartaee-platform-dev] VOTE: Specifications to add in
JakartaEE 9
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
I
think that!/s clearly a Question for many of the legal Folks
at Eclipse
Foundation and others (especially Oracle who was the main or
only contributor
during JCP times) if the reverse direction of other discussed
possibilities
like graduating selected MicroProfile features into Jakarta EE
specs was
also possible?
Under
an assumed Name of "microprofile-jaxb"
or similar.
No
Need to be a lawyer, that it must neither Keep the javax nor a
jakarta
Namespace anywhere, if such a fork was even possible.
Werner
From:
Markus
KARG
Sent: Tuesday, November 26, 2019 20:12
To: 'jakartaee-platform
developer discussions'
Subject: Re: [jakartaee-platform-dev] VOTE:
Specifications to add in
JakartaEE 9
If
nobody else wants JAXB, I could offer to further maintain it
separately
as a EF project outside of the Jakarta EE platform scope.
So
you do not have to care about it, and I would care about those
people that
like to get it enhanced.
-Markus
Von:jakartaee-platform-dev-bounces@xxxxxxxxxxx
[mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Amelia Eiras
Gesendet: Montag, 25. November 2019 23:49
An: jakartaee-platform developer discussions
Betreff: Re: [jakartaee-platform-dev] VOTE:
Specifications to add in
Jakarta EE 9
if
so, what do we do with Mark K.s Nov 18th written feedback on
active contributors
to JAXB? ... JAX-WS?
direct
quote:
There
still are people out there who actively use JAXB and who even
like to contribute
new features to drive new releases of JAXB (me included).
It
is not possible to make everyone happy while the renaming
occurs yet I
like the idea of later time "evolving those API" yet I worry
that today we already know that there are contributors, via
actions do
we choose to tell them that their collaborations must stop
until they rally
forces to prove us wrong b/c their voice today is not enough
prove.
there
is no neutral ground in this ecosystem, there is this forum
that traces
how we get to a future. :) lets keep this thread going!
Amelia
Eiras
twitter.com/ameliaeiras
Tribe:http://tomitribe.com https://tribestream.io
OSS:http://microprofile.io https://jakarta.ee
On
Mon, Nov 25, 2019 at 2:35 PM Kevin Sutter <sutter@xxxxxxxxxx>
wrote:
-1
I think the JAXB and JAX-WS question has to be answered. I
think
we either need to add both of them, or neither of them. At
this point,
I would prefer that we don't add either of them. Let both
JAXB and
JAX-WS to continue to live in their current state using the
javax package
name. If we get enough interest in evolving these and
supporting
these in the future, then we can entertain bringing them
forward -- maybe
as standalone Specs under EE4J, maybe as part of the Platform.
But,
let's not make this decision right now. There are several app
servers
that already support Java SE 11 with these "missing" features
and they have figured out a way to support them. Let's leave
it that
way until someone shows a need and desire to move them.
I'm okay with Activation since Bill has shown an interest in
moving that
forward for Jakarta EE mail. But, even if that got "dropped"
to be consistent with none of the Java SE technologies moving
into Jakarta
EE, I would be fine with that as well.
---------------------------------------------------
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:58
Subject: [EXTERNAL]
[jakartaee-platform-dev] VOTE: Specifications to add 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
added from
Java SE 8 to the Jakarta EE 9 platform specification.
The
following APIs corresponding to Java SE 8 APIs will be
added
to Jakarta EE 9 Full Profile
-
Jakarta XML Binding
-
Jakarta Activation
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
_______________________________________________
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
