[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec.committee] BALLOT: Approval to restructure as specification projects (round three)
|
+1 for IBM (covering
for Dan)
---------------------------------------------------
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:
Wayne
Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>Date:
06/25/2019
03:17 PMSubject:
[EXTERNAL]
[jakarta.ee-spec.committee] BALLOT: Approval to restructure as
specification projects (round three)Sent
by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
Greetings Specification Committee...
Here is the second round of conversions from regular Eclipse Projects into
Specification Projects. I've grouped five projects into this first Restructuring
Review.
The purpose of a Restructuring Review is to change the nature of a project.
Since the Eclipse Foundation Specification Process (EFSP) does not specifically
deal with the notion of restructuring, I'm following the Eclipse Development
Process (EDP). While we are not strictly creating a new project, we are
in a manner of thinking, creating new Specification Projects from the existing
ones. With this in mind, I am treating this as a Creation Review from the
perspective of the Specification Committee approval requirement.
I have created a Restructuring
Review record that provides
the high level details of the intention. I've pasted it below for your
quick review and for posterity. In all cases, I've included the scope statement
for the specification itself; the specification project's scope will be
to "provide the specification document and supporting technical artifacts"
for the corresponding specification.
The review documentation includes links to GitHub Issues that provide more
details regarding what will change.
Here is the project list:As
we convert existing projects into Specification Projects, as defined by
the Eclipse Foundation Specification Process, we will split a new Specification
Project off from the Eclipse Mojarra project. Following this split, the
Eclipse Mojarra project will continue to exist as a compatible implementation
of the Jakarta Server Faces specification, which will be defined by the
new Jakarta
Server Faces project
with this scope:
Jakarta
Server Faces defines an MVC framework for building user interfaces for
web applications, including UI components, state management, event handing,
input validation, page navigation, and support for internationalization
and accessibility.
We
will rename the "Eclipse
Project for JavaMail"
project to "Jakarta Mail" and convert it into a specification
project with this project/specification scope statement:
Jakarta
Mail defines a platform-independent and protocol-independent framework
to build mail and messaging applications.
We
will rename the "Eclipse
Project for JCA"
project to "Jakarta Connectors" and convert it into a specification
project with this project/specification scope statement:
Jakarta
Connectors defines a standard architecture for Jakarta application components
to connect to Enterprise Information Systems.
We
will rename the "Eclipse
Project for Stable Jakarta EE APIs"
project to "Jakarta Stable APIs" and convert it into a specification
project with this project/specification scope statement:
Jakarta
Stable APIs provides a home for stable (legacy) Jakarta EE specifications
which are no longer actively developed.
Jakarta
Management defines a standard management model for exposing and accessing
the management information, operations, and parameters of the Jakarta EE
Platform components.
Jakarta
Deployment defines standard APIs that will enable any deployment tool that
uses the deployment APIs to deploy any assembled application onto a Jakarta
EE compatible platform.
Jakarta
XML Registries describes Java API's designed specifically for an open and
interoperable set of registry services that enable sharing of information
between interested parties. The shared information is maintained as objects
in a compliant registry. All access to registry content is exposed via
the interfaces defined for the Registry Services.
Jakarta
XML-based RPC defines consistent Java APIs for using XML based RPC standards.
We
will rename the "Eclipse
Project for Common Annotations"
project to "Jakarta Annotations" and convert it into a specification
project with this project/specification scope statement:
Jakarta
Annotations defines a collection of annotations representing common semantic
concepts that enable a declarative style of programming that applies across
a variety of Java technologies.
We
will rename the "Eclipse
Project for Interceptors"
project to "Jakarta Interceptors" and convert it into a specification
project with this project/specification scope statement:
Jakarta
Interceptors defines a means of interposing on business method invocations
and specific events—such as lifecycle events and timeout events—that
occur on instances of Jakarta EE components and other managed classes.
We
will rename the "Eclipse
Project for JAX-WS"
project to "Jakarta XML Web Services" and convert it into a specification
project with this project/specification scope statement:
Jakarta
XML Web Services defines a means for implementing XML-Based Web Services,
Web Services Metadata, and SOAP with Attachments.
We
will rename the "Eclipse
Project for JACC"
project to "Jakarta Authorization" and convert it into a specification
project with this project/specification scope statement:
Jakarta
Authorization defines the installation and configuration of authorization
providers for use by containers. The specification defines the interfaces
that a provider must make available to allow container deployment tools
to create and manage permission collections corresponding to roles.
We
will rename the "Eclipse
Project for Enterprise Security"
project to "Jakarta Security" and convert it into a specification
project with this project/specification scope statement:
Jakarta
Security defines a standard for creating secure Jakarta EE applications
in modern application paradigms.
We
will rename the "Eclipse
Project for _expression_ Language"
project to "Jakarta _expression_ Language" and convert it into
a specification project with this project/specification scope statement:
Jakarta
_expression_ Language defines an _expression_ language for Java applications.
I hereby request that the Specification
Committee vote to approve the conversion as described above of these existing
projects into Specification Projects under the supervision of the Jakarta
EE Working Group.
Please respond to this note with:
+1 to approve;
-1 to reject; or
0 to abstain.
If you do choose to reject or abstain, I would appreciate a short (one
or two sentence) explanation.
I will interpret a single vote as applying to all of the listed projects.
You may also vote for each project individually (if, for example, you'd
like to register different votes for each projects).
I will document the results of this vote on a per-project basis.
Thanks,
Wayne-- Wayne
Beaton
Director
of Open Source Projects | Eclipse
Foundation, Inc._______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee