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
