Re: [jakarta.ee-spec.committee] BALLOT: Approval to restructure as speci

["Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>]

+1 Payara

 

From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Wayne Beaton
Sent: 25 June 2019 21:17
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: [jakarta.ee-spec.committee] BALLOT: Approval to restructure as specification projects (round three)

 

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.