Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] Specification Process Goals/Requirements
Thank you, Wayne and Mike.  This is an excellent foundation for getting things started!

I have thoughts on all of the topics listed here and I’m sure others do as well and that there will be disagreements to work out.  I don’t think we can address all of this efficiently in our inaugural meeting - or any meeting. There is just too much there.   Would it be premature to address these issue, where possible, in separate email threads?   Using email to flush out issues and ideas and then using the Comittee meetings to make decisions or delegate tasks seems to me to be a healthy approach in terms of providing a public record and not bogging down meetings with technical and process debates.

On Wed, May 2, 2018 at 12:53 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Greetings folks.

Mike and I have assembled a starting point for some goals/requirements for the specification process. We're hoping to use this as a starting point for our discussion on Friday.

Mike will be on the call.

Thanks,

Wayne

Goals/Requirements

  • There are three separate, but related aspects to this process:

    • The development of the specifications themselves;

    • The process of ratifying and promoting official specifications; and

    • Certification of implementations of ratified specifications.

  • Open Source: The specification process should be based on open source best practices of openness, transparency, and meritocracy.

  • Standalone: It should be possible for an implementation of each specification to run on its own on top of Java SE, or with as small a list of additional prerequisites as possible. The Jakarta EE Full Profile (a.k.a. the Jakarta EE Platform) is backwards compatible with the Java EE Platform and will continue to include all of the specs provided by Oracle when Jakarta EE launched.

    • Note: the above is a goal. Obviously it will take resources to accomplish this, and we cannot state at the moment when this could be delivered.

    • Question: In the future, does it still make sense to require that the Platform include every spec developed under the Jakarta EE brand? I think I can imagine scenarios where we want to add new specs which are *not* included in Platform.

    • Question: Is the Jakarta EE Platform specifically targeted at on-premise deployments? Can anyone imagine a cloud-based deployment of the entire Platform? If this is true, should the current Java EE Platform be rebranded to the Jakarta EE Server Profile?

    • Note that the above significantly changes the role of the specifications. Rather than defining a single large platform, we are defining a collection of specifications which are included in a collection of profiles.

      • If we no longer have a single large server definition as the explicit goal, then perhaps it would be possible to consider having different profiles releasing on different timetables. Does it really make sense to insist that the Microservice Profile and the Server Profile have to release on exactly the same day? What are the implications of that idea?

  • Profiles: We need to have a well-defined and relatively lightweight process by which new profiles can be defined.

    • A Profile is simply a collection of specifications which are combined to produce a runtime, and version managed together.

    • A Profile may have an additional Specification and TCK beyond just those of its constituent parts.

    • Strawman: A Profile may be created with the support of at least three Jakarta EE Strategic Members. (The reason to tie it to them is that ensures that at least there are some vendors that want to support this profile in their products.)

  • Ratification/Promotion: Specification development produces some collection of artifacts. What is the process to take that collection of artifacts, ratify them, and promote them to official status?

  • Compatibility: All stakeholders in Jakarta EE have reiterated their desire to retain a strong notion of compatibility, tied to a logo-based certification process. Given the standalone and profile goals above, it probably makes sense to tie certification to profiles. E.g. a vendor would certify that their independent implementation would be “Jakarta EE Web Profile” certified.

    • Does the process support any notion of certification of any implementation of any (Jakarta EE) specification?

    • Does the process only support certification of implementations of profiles? Just some profiles? If only a subset, how is that subset selected?

  • Java SE Currency: Jakarta EE needs to have a stated position on how current it will stay with Java SE releases.

    • Related: When will Jakarta EE embrace Java 9 and Jigsaw modularity?

  • Release Cadence: Jakarta EE needs to have a stated position on how frequently releases of the specification are done. I think it is perfectly fine to say “we don’t know yet” up until we ship Jakarta EE 9 in (say) Q2 2019.

Certification of Compatibility: Certification of independent implementations as meeting compatibility requirements will be made transparently by the Specification Committee. (E.g. the materials provided to the committee demonstrating compatibility, and the decision of the committee will be part of the public record.)


--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec
--
Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io

Back to the top