Thanks for the info.
-Markus
From: ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Kevin Sutter
Sent: Mittwoch, 5. Juni 2019 15:02
To: EE4J PMC Discussions
Subject: Re: [ee4j-pmc] Specification Projects and the Jakarta Namespace
Markus,
I just found yesterday that the first round of Spec Projects may be delayed a week or two. You probably saw Wayne's message yesterday that JAX-RS is still on the short list:
https://www.eclipse.org/lists/ee4j-pmc/msg01939.html
---------------------------------------------------
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 04:28 PM
Subject: [EXTERNAL] Re: [ee4j-pmc] Specification Projects and the Jakarta Namespace
Sent by: ee4j-pmc-bounces@xxxxxxxxxxx
Kevin,
thanks for the answer. This sounds promising. :-)
-Markus
From:ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Kevin Sutter
Sent: Samstag, 1. Juni 2019 21:54
To: EE4J PMC Discussions
Subject: 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/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
