[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ee4j-pmc] Specification Projects and the Jakarta Namespace
|
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/kevinwsutterFrom:
"Markus
KARG" <markus@xxxxxxxxxxxxxxx>To:
"'EE4J
PMC Discussions'" <ee4j-pmc@xxxxxxxxxxx>Date:
06/01/2019
06:46 AMSubject:
[EXTERNAL]
Re: [ee4j-pmc] Specification Projects and the Jakarta NamespaceSent
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