Markus,
Once the
JAX-RS
project has become a Specification Project, then you are green
to use the
JESP. Since your team always seems to be pushing the envelope
(and
us), I'm pretty sure the JAX-RS project is on the first batch of
projects
to be reviewed and accepted. Wayne has a small batch of
projects
for the review on June 5 to become Specification Projects. I
believe
JAX-RS is on that short list. Once the review passes, then
provisioning
can start.
We are also
discussing
how and when to make a clear separation between the Spec/API/TCK
and the
Implementation projects. Since JAX-RS API is separate from the
Jersey
Impl, that should be relatively straight forward for your
project. Others
are not quite as simple (ie. JavaMail).
The Spec
documents
were just received by the Eclipse Foundation this past week.
They
are going through the necessary IP verification before getting
posted to
the respective projects. I really don't know how long that will
take,
but hopefully not that long.
You are free
to
start making the move to the jakarta.* namespace. Two things to
be
aware of... 1) You can not do any official github releases
of jakarta namespace content. Not until we get the JESP in
place
for JAX-RS. Snapshot, milestone, early releases are fine, but
you
can't do any official major.minor releases of jax-rs with the
jakarta namespace.
And, 2) Be aware that there is still the discussion about the
extent
of the Package renaming that will be allowed for Jakarta EE 9.
It
may be a requirement that only the javax -> jakarta package
name change
will be allowed (with the rest of the package name, class names,
and method
names staying the same). If you go too far with your changes,
you
may be required to change back to minimal changes.
Hope this
helps
with your continued progress. Thanks for the questions.
---------------------------------------------------
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:
"'EE4J
PMC Discussions'" <ee4j-pmc@xxxxxxxxxxx>
Date:
06/01/2019
06:46 AM
Subject:
[EXTERNAL]
Re: [ee4j-pmc] Specification Projects and the Jakarta Namespace
Sent
by: ee4j-pmc-bounces@xxxxxxxxxxx
PMC,
when
and how can we initiate the Jakarta EE Specification Process
for JAX-RS
2.2? To be more specific, when will the TCK be split up (and
by whom) so
that the JAX-RS committers can extend their part of the test
suite according
to the new features of JAX-RS 2.2, and when will we gain
access to the
Spec document to modify it accordingly?
As
JAX-RS 2.2-SNAPSHOT already contains new functionality, that
branch MUST
switch to the jakarta namespace anyways, so further waiting
makes no sense
to us. Why shouldn't we do that right now?
-Markus
From:ee4j-pmc-bounces@xxxxxxxxxxx
[mailto:ee4j-pmc-bounces@xxxxxxxxxxx]
On Behalf Of Ivar Grimstad
Sent: Samstag, 1. Juni 2019 12:55
To: EE4J PMC Discussions
Subject: [ee4j-pmc] Specification Projects and the
Jakarta Namespace
TL;DR
As
has been noted in past
postings to the PMC mailing list,
several of the EE4J Projects are going through the
transformation to becoming
Specification Projects. To that end, these Specification
Projects
will be following the Jakarta
EE Specification Process,
which is a slight derivative of the Eclipse
Foundation Specification Process.
Until this transformation is complete for your API project,
it is
advised to not perform additional “official” Github releases.
Milestone
or Release Candidate or Alpha/Beta releases are fine -- just
not “Major.Minor”
releases.
Reasoning...
The
Jakarta EE Specification Process outlines the Release
Process for Specificationsand the associated APIs and
TCKs. There is a clear distinction between
the Github development releases and the official, “ratified”
releases.
This process is required in order to ensure proper IP flow
from the
Specification Project to the corresponding implementers of
said Specifications.
Implementing against a Github release of an API does not
protect
the IP grants.
During
the process of ratifying a Specification release, the
corresponding Github
release is presented as a read-only snapshot of the proposal.
Thus,
no additional development is allowed during this Specification
release
process. Once the Specification release is approved by the
Specification
Committee, then the Github release artifacts will be moved to
a proper
repository and be made available under the Eclipse
Foundation Specification License.
This Specification version is the one to be used by
implementers.
Additional
Reasoning…
As
many of you know, there is also a lively
discussion on the Platform-Dev mailing list about
the move from the javaxnamespace to the jakartanamespace -- whether
we should do this incrementally or all-at-once (big
bang). Until that discussion commences and a
decision/direction has
been determined, projects should not be expending effort on
making any
type of jakartanamespace changes.
For example, if an incremental approach is decided,
then not every project will be requiring these namespace
updates.
Ivar
- on behalf of the EE4J PMC_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
