| We did write an app that can be used to do calculations on the effects of package renames:
Activation could be left in javax and not affect any other packages. However, if JAXB is renamed then JAX-WS would remain in a broken state. People wouldn't be able to compile JAX-WS code unless the old JAXB was included.
-- David Blevins 310-633-3852
This is good, Markus.
If there are still changes required in the JAXB API, then by all
means this should be moved into the Jakarta realm. I was really questioning
whether either of these two APIs need any further evolving. If you're
saying that JAXB does, then that's good input.I also discovered
that Jakarta Mail requires Activation. But, even with that dependency,
does the API still need to evolve? Or, could Jakarta Mail just have
a dependency on Java Activation? Probably a question for Bill..
---------------------------------------------------
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:
"Markus
KARG" <markus@xxxxxxxxxxxxxxx>To:
"'jakartaee-platform
developer discussions'" <jakartaee-platform-dev@xxxxxxxxxxx>Date:
11/18/2019
16:38Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] VOTE: Specifications to add in
Jakarta EE 9Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
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).This is independent of the Jakarta EE platform actually, but it enforces
a rename of the packages to "something-other-than-javax" still.
As the projects are given to the EF, it simply comes in mind that treating
them as if they would be parts of Jakarta EE might be the simplest solution.
Certainly, any other package name would do, certainly. But the question
is, who decides about these projects if they are not wanted to be parts
of Jakarta EE? -Markus Before
I cast a vote, can I ask why these two APIs (XML Binding and Activation)
need to move to Jakarta EE? Why can't we use the same argument as
the SOAP API? Implementations can continue to use the javax versions
of the XML Binding and Activation APIs, but they just will not evolve in
the Jakarta EE space. Do we expect a need for these two APIs to continue
to evolve? Or, maybe we have some dependencies on these APIs by other
Jakarta specs that require these to be moved? I realize these were
part of Bill's original proposal and there was much more discussion on
the other APIs that we decided not to move. But, why did we decide
that these two were required?
---------------------------------------------------
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@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
