No problem, and no offence, but from the view angle of a "reiceiver" it is better to have clear "please wait the official answer is in progress" statement that any kind of "possibly, maybe, AFAIKs, etc". Hope you don't mind, but personal views just confuse us. We need not more statements, we need less -- but official ones.
-Markus
Markus,
Wayne's statements are about the best that exist at this moment... :-) He is part of the EF and part of the PMC. As soon as any of us knows (and Wayne will probably be first), I'm sure there will be more official statements coming about the Specs. As Wayne has indicated, the EF just received the Specs from Oracle and the proper IP scanning and clearance activities are happening as we speak. Thanks for your patience.
---------------------------------------------------
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/06/2019 11:25 AM
Subject: [EXTERNAL] Re: [ee4j-pmc] First round of project restructuring
Sent by: ee4j-pmc-bounces@xxxxxxxxxxx
It would be good to be absolultely clear about any "as far as I know" issues. Can the PMC please post an official and final statement here instead of any "as far as I know"s?
And what actually do we have to change in the specs ontop of "simply adapting the original doc"?
-Markus
From:ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: Donnerstag, 6. Juni 2019 15:50
To: EE4J PMC Discussions
Subject: Re: [ee4j-pmc] First round of project restructuring
The existing document is not, as far as I know, licensed in a manner that permits you to "simply adapt the original spec doc". The Eclipse Foundation is working on getting the necessary rights to change the license of these documents and contribute them to the corresponding projects.
Wayne
On Thu, Jun 6, 2019 at 1:10 AM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
I do not see a need for a placeholder spec for JAX-RS but would simply adapt the original spec doc according to the needed changes. So please put me on the CC list for the JAX-RS asciidoc spec. Thanks.
-Markus
From:ee4j-pmc-bounces@xxxxxxxxxxx[mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: Donnerstag, 6. Juni 2019 05:47
To: EE4J PMC Discussions
Subject: [ee4j-pmc] First round of project restructuring
Thank you for your patience, PMC.
PMC, and project leads:
I intend to push the projects listed as "Review Documentation" at the bottom of this message through our first restructuring review to turn existing "Eclipse Project for ..." projects into specification projects.
Note that I'd like to have the Jakarta EE Platform project included in this list, but I need a little help with the scope statements(the platform project actually includes three specifications). I'll bring that forward as soon it's ready.
I'd like to send this list to the Specification Committee as soon as possible; if you have any feedback or concerns, or feel that a little extra wordsmithing is required let me know. I've also included an overview of the process that I'm following. Likewise, let me know if you've noticed something amiss with the process.
I'm tracking all of the change issues here. There's pointers to the scope and name issues in the individual cards.
The Process
My plan is to deliver this list to the Specification Committee with a request for them to vote to approve the conversion of the existing projects into specification projects. Per the process, we require a super-majority (2/3) affirmative vote to proceed. I'm presenting them as an all-or-nothing collection (we'll adjust this part of the process if there's a problem).
I will concurrently start a Restructuring Review per the EDP. I'll include the content below as the documentation for that review. Both the community review and the Specification Committee vote aspects of the Restructuring Review require a week; when that week is over, I'll declare success (assuming that we get the specification committee votes we required and the PMC gives me their approval)
With the successful conclusion of the review, I will convert the projects. As part of this, I will review the committer lists to ensure that we have all of the necessary agreements for all of the committers. I will retire any committers who do not have the necessary agreements in place (we'll reinstate them when we get the paperwork that we need). I will then update the project metadata based on the described changes.
Note that some of these projects will require some changes in the names of their repositories to respect trademark restrictions (e.g. "jaf-api" will become "activation-spec"). We will also have to change the ids of some projects. I've captured these changes in the project board that I cited previously.
With that all done, it will be left to the project teams to start with the work of creating specification documents. The PMC will provide guidance regarding the form of these documents. The short version is that for many of these specifications, we'll have to ask the project teams to create "placeholder" specification documents based on the project name, scope, and javadoc (more on this later).
We're working through an exercise to get the necessary rights to contribute the existing specification documents under the project licenses. At this point, I do not know which documents we'll clear first.
Regarding the existing specification documents... when I am able to do so, I will contribute the specification to the project via IPZilla (with project leads in CC). The project team can take the specification and drop it into their repository when the IP Team gives their approval (the IP Team is involved in the above-mentioned exercise, so approval will come immediately/quickly). The PMC will provide guidance to project teams regarding what needs to happen next.
Note that the PMC's recommendation is that the "API" repository be used as a home for both the API and for the specification document. We are moving forward based on this assumption. Since project teams will be the ones who will either create placeholder documents or take the existing document out of the IPZilla record, they will have an opportunity to request the the webmaster create a separate repository if that's what they prefer. Project teams may feel free to weigh in on the "convert" issues if they'd like to get ahead of it.
Note also that the specification documents that we have are all in Asciidoctor format.
I will track all of this activity in the "convert" issues. Monitor those issues to keep up with progress of the individual projects.
Review Documentation
Eclipse Project for JAX-RSwill be renamed to "Jakarta RESTful Web Services" with the following specification scope:
Jakarta RESTful Web Services defines a standard for development of web services following the Representational State Transfer (REST) architectural pattern.
Eclipse Project for JSON Processingwill be renamed "Jakarta JSON Processing" with the following specification scope:
Jakarta JSON Processing defines a Java(R) based framework for parsing, generating, transforming, and querying JSON documents.
Eclipse Project for JAFwill be renamed "Jakarta Activation" with the following specification scope:
Jakarta Activation defines a set of standard services to: determine the MIME type of an arbitrary piece of data; encapsulate access to it; discover the operations available on it; and instantiate the appropriate bean to perform the operation(s).
Eclipse Project for JPAwill be renamed "Jakarta Persistence" with the following specification scope:
Jakarta Persistence defines a standard for management of persistence and object/relational mapping in Java(R) environments.
Eclipse Project for WebSocketwill be renamed "Jakarta WebSocket" with the following scope:
The Jakarta WebSocket defines how Jakarta based applications create and manage WebSocket Clients and Servers.
Thanks,
Wayne
_______________________________________________
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
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc._______________________________________________
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
