Let me be more
definitive...
The current Oracle-owned specification documents are not
licensed in a manner that allows you to simply adapt them for
Jakarta EE. Once Eclipse has obtained all the necessary
rights, they will relicense each document and provide them to
the project teams.
Project teams should also plan to do some non-trivial work on
the documents after receiving them. The documents will
contain Java EE names and JCP references that will need to be
replaced. Although the documents will be provided in AsciiDoc
format, the conversion to AsciiDoc from FrameMaker or LaTeX or
Word was not perfect. Most documents will need some cleanup
to correct formatting problems. All of the images used by the
documents will be provided in png format. If any updates are
required to the images (e.g., to correct names), the images
will likely need to be recreated in some more easily editable
format.
If any project teams make any improvements to the tools used
to generate the specification documents, I hope they'll share
them with the rest of us.
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
_______________________________________________
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
