|
The Jakarta EE technologies that are specifically referenced in
the Jakarta EE Platform are listed in the Jakarta EE
specification. See B.2
Java EE 8 Specification References (JAXB is listed here).
The components necessary for evolution of these Java SE deprecated
components are contributed to Eclipse Foundation. The project is
free do decide how to use these, moving forward. Currently,
Jakarta EE 8, requires these technologies to be available.
Also, in the Steering committee meeting, earlier today, there was
some discussion about what technology components are currently
optional. For Jakarta EE 8, these are also listed in the Platform
specification document. See 9.6
Optional Features for Jakarta EE Profiles. and the set of
technologies that are listed as optional (the bottom section of
the bullet list under optional technologies) in 9.7
Full Jakarta EE Product Requirements.
Presumably, when this discussion completes, we will be intent on
adjusting these lists for Jakarta EE 9.
-- Ed
On 11/26/2019 3:18 PM, arjan tijms
wrote:
It was provided by Java SE indeed, but
wasn't it nevertheless still an API that was supposed
to be in Java EE? I could be completely mistaken here
though. TBH, it's indeed a little confusing, which is
probably part of the reason Java SE removed it. There
were upstream Java EE versions of those APIs, and
the Java SE versions were lagging behind (I remember
the @Resource issue with the lookup attribute).
See
Anyway, point taken, ignoring some of the fuzzy
details and semantics this vote is mainly about
adding in. Thx!
Kind regards,
Arjan
AFAIK JAXB currently isn’t in
the Jakarta EE 8 full profile it was provided by Java
SE. The vote is to add it in not remove it from.
However as others have said this leads to complexity
with JAX-WS.
Steve
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx
<jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of arjan tijms
Sent: 26 November 2019 22:44
To: jakartaee-platform developer discussions
<jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] VOTE:
Specifications to add in JakartaEE 9
Hi,
If some of the specs such
as JAXB get removed from the full profile,
though still evolved and/or provided via the
EE4J project, then it kinda resurrects the
"legacy free profile" idea that was floated
before. The Full Profile effectively becomes
that Legacy Free Profile then, and Full itself
disappears.
JAXB is surely still used a
lot, as XML itself is still quite a viable
format. With the exception of JAX-RS it's most
often used as an implementation level
dependency, and as such I'm sure it still
warrants a certain level of maintenance. The
big question is here if the API would ever
need to be evolved, or that the
countless dependees will seek out potential
enhancements in the JAXB implementations such
as org.glassfish.jaxb:jaxb-runtime.
As have been said before we
are only discussing what is to be included in
the Full/Web Profile of the Jakarta EE 9
platform spec.
Any spec we decide not to add
or we decide to prune still exists and can still
evolve within the Jakarta spec process and EE4J
top level project if committers are interested.
Also the pruned spec can still be included by a
product or used standalone. Not being included
in the platform spec just means a vendor is not
required to provide an implementation to get the
compatibility logo.
Steve
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
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
if so, what do we do with Mark
K.s Nov 18th written feedback on active
contributors to JAXB? ... JAX-WS?
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!
-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
|
