Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakarta.ee-spec.committee] Review for approval: Spec Committee Meeting Minutes May 15th and May 22nd, 2019

HI All,

I do realize that this is a very short notice, but never the less if you get a chance to review the below meeting minutes we can approve them today, otherwise we will deffer approval for the next call.

Here is the link to the document for people who prefer that.

Spec Committee Agenda May 22nd, 2019

Attendees (present in bold):

Kenji Kazumura - Fujitsu, Michael DeNicola

Dan Bandera - IBM, Kevin Sutter, Alasdair Nottingham, BJ Hargrave

Bill Shannon - Oracle, Ed Bratt, Dmitry Kornilov, Jim Wright, Will Lyons

Steve Millidge - Payara, Arjan Tijms

Scott Stark - Red Hat, Mark Little, Antoine Sabot-Durand

David Blevins - Tomitribe, Richard Monson-Haefel, Jean-Louis Monterio

Ivar Grimstad - PMC Representative

Alex Theedom - Participant Member

Werner Keil - Committer Member


Eclipse Foundation: Wayne Beaton, Tanja Obradovic, Paul Buck, Mike Milinkovich


  • Past business / action items

    • Approval of Meeting min May 15th.  DEFERRED

  • Moving forward without the javax namespace

  • Jakarta EE 8 release

    • Jakarta EE 8 release plan - Ed Bratt

    • Specification Document Copyrights (Wayne)

      • We have the list of copyright holders provided by Oracle and have started the process of consolidating the list (i.e. tracking acquisitions to determine current copyright holders)

      • Agreement document created and signed by three companies, and two individuals.

      • Focusing on Platform first

      • ACTION (Wayne) develop a trackable metric.

    • Index of specification documents and associated artifacts.

    • Ballot Process

      • We need to have a more transparent means of disseminating the results of specification committee votes.

      • ACTION (Scott) describe the problem and take initial leadership.

      • TODO Need a means to track other ballots.

    • Restructuring Review

    • Jakarta Batch is good to go.

      • ACTION (Wayne) initiate the required (albeit late) specification committee ballot to approve creation. (DONE)

    • CDI

      • Red Hat has decided to move the API and specification for CDI to Eclipse EE4J

      • ACTION (Scott) create a project proposal.

    • Dependency Injection

      • ACTION (Paul Buck) Is anybody tracking what we’re doing with the dependency injection specification?

    • Bean Validation (Jakarta Bean Validation)

      • Red Hat will move to Eclipse Foundation

      • ACTION (Scott) Create a new project proposal for Jakarta Bean Validation.

    • JavaServer Faces (Jakarta Server Faces)

      • APIs are part of Eclipse Mojarra. Recommend that we leave them there.

      • ACTION (Wayne) Create a new project proposal for Jakarta Server Faces. Wayne will identify the best candidates to start the project proposal process.

    • Acronyms

      • Ivar suggested on the May 21/2019 Steering Committee call that we drop acronyms altogether in favour of concise (short) project names.

        • E.g. “Jakarta Persistence” is “Persistence” and not “JPA”

        • EJB?

      • There appeared to be general consensus among those who attended the call that this would be a good idea.

      • Wayne: does this apply to the technical namespaces?

        • General consensus was: where possible, yes.

        • This is already true for many specifications:

          1. javax.persistence.* => jakarta.persistence.*

          2. javax.transaction.* => jakarta.transaction.*

        • Simplify and consolidate where possible:

          1. javax.ws.rs => jakarta.rest.*

        • Some will just be different acronyms:

          1. javax.ejb => jakarta.jeb.* (“Jakarta Enterprise Beans”)

    • TCK Process Status?

      • TCK process - Scott Stark leading the effort

      • TCK Processes should be integrated into the operations document.

      • The EMO cannot manage either the creation or the ongoing application of TCK processes; this is the responsibility of the specification committee. Either the specification committee or PMC will be required to take responsibility for determining whether or not the requirements of the TCK have been fulfilled as part of their approval process.

        • Scott is working on this.

        • Needs another pass.

        • QUESTION: How do we change an EPL-licensed TCK into an EFTL TCK? Who creates the EFTL version?

        • ACTION (Wayne) QUESTION: Do we need a click-through license acceptance to get access to the TCK/other resources (Eclipse legal question)?

  • PMC update - Ivar Grimstad

  • Specification Template

    • ACTION (Arjan Tijms) update specification Template and experience going through

      • We’ll discuss on a later call, once we finish javax namespace discussion


Spec Committee Agenda May 15th, 2019

Attendees (present in bold):

Kenji Kazumura - Fujitsu, Michael DeNicola

Dan Bandera - IBM, Kevin Sutter, Alasdair Nottingham, BJ Hargrave

Bill Shannon - Oracle, Ed Bratt, Dmitry Kornilov, Jim Wright, Will Lyons

Steve Millidge - Payara, Arjan Tijms

Scott Stark - Red Hat, Mark Little, Antoine Sabot-Durand

David Blevins - Tomitribe, Richard Monson-Haefel, Jean-Louis Monterio

Ivar Grimstad - PMC Representative

Alex Theedom - Participant Member

Werner Keil - Committer Member


Eclipse Foundation: Wayne Beaton, Tanja Obradovic, Paul Buck, Mike Milinkovich


  • Past business / action items

    • Approval of Meeting min May 8th. Mike DeNicola moves to approve; Scott seconds. No objections.

  • Moving forward without the javax namespace

    • Status of Javax thread on Platform list

      • “Healthy and active”. Variety of opinions on how to move forward.

      • David has started to summarize evolving consensus (GitHub).

      • Question: is David keeping track of numbers?

        • “Informative instead of definitive”

      • Do you think overall that the audience understands the issues?

        • Clarifying questions seem to indicate yes.

        • Does the next version of the platform have to provide backwards compatibility? Source code vs. binary compatibility? What do we really mean by compatibility? Scott will start this discussion.

    • Link to the latest email / document

    • Scott has pushed the binary compatibility discussion document.

    • ACTION (All): Request for comment on either the pull request or mailing list discussion https://github.com/eclipse-ee4j/jakartaee-platform/pull/15

  • Jakarta EE 8 release

    • Jakarta EE 8 release plan - Ed Bratt

      • Update the operations document with content from Ed’s document.

        • Scott has produced Steps to Complete JESP for Jakarta EE 8

https://docs.google.com/document/d/12DsBDdDVO-jnOrrZYnOjx0tuAzZcoTumO6GvyS5c_DY/edit

        • ACTION (All): Review the document and provide feedback.

        • Discussion regarding index of specification documents and associated artifacts. Index manifests as website (similar to what the JCP does). Scott will add gathering requirements for this to the document.

        • ACTION (?): Create an issue to track requirements for the addition of an index of specification to the Jakarta EE website here: https://github.com/jakartaee/jakarta.ee

      • Wayne will walk the first round of projects through the process of converting existing projects into specification projects. As part of this, Wayne will generate a step-by-step guide to assist project teams with understanding the process. Note that this is a one-time/unique process, and that the guide will be crafted with this in mind.

        • Not complete yet.

        • ACTION (Wayne): set up the first round of restructuring reviews

          1. We currently have four projects that have complete committer lists (i.e. all committers are covered by an updated committer agreement, a membership agreement, and a Jakarta EE Working Group Participation Agreement)

            1. JAF, JAX-RS, JSTL, and Orb

            2. These are the best candidates for the first round of specification project conversions.

        • Jakarta Batch is good to go.

          1. ACTION (Wayne) initiate the required (albeit late) specification committee ballot to approve creation.

        • ACTION (?) Get the marketing committee engaged.

        • Bill expressed that we need to have a more transparent means of disseminating the results of specification committee votes. Wayne recommended starting the discussion on the mailing list and taking it to a GitHub issue. This is related to the index. Scott will describe the problem and take initial leadership.

      • The EMO cannot manage either the creation or the ongoing application of TCK processes; this is the responsibility of the specification committee. Either the specification committee or PMC will be required to take responsibility for determining whether or not the requirements of the TCK have been fulfilled as part of their approval process.

        • Scott is working on this.

        • Needs another pass.

        • QUESTION: How do we change an EPL-licensed TCK into an EFTL TCK? Who creates the EFTL version?

        • QUESTION: Do we need a click-through license acceptance to get access to the TCK/other resources (Eclipse legal question)?

      • TCK Processes should be integrated into the operations document.

      • Suggestion: create a committee to sort out the TCK processes and related issues. We need to move on this quickly and the weekly cadence isn’t enough.

      • Scott volunteered to help with the development TCK processes (this effort is currently being led by David).

      • Wayne volunteered to produce a list of names of project leads so that company representatives can identify them and chase them down to engage in the process. Bill scraped data from the website and posted it in the meantime (so Wayne considers this action item complete).

      • The Jakarta Batch project is ready to push forward.

      • Wayne suggested that having the specification document at the Eclipse Foundation is the minimum bar for the four specifications not currently hosting resources with us.

        • QUESTION: Is anybody tracking what we’re doing with the dependency injection specification? Paul will sort this out.

        • ACTION (Scott) investigate options for the Red Hat specifications.

          1. No update regarding API/TCK.

          2. Specification documents (e.g. CDI, bean validation) will be hosted by an Eclipse Foundation specification project.

          3. Can we consume the CDI TCK as a third party content and redistribute under the EFTL?

          4. What needs to be done to include CDI and bean validation in Jakarta EE 8.

          5. What’s going on with dependency injection.


    • Discussion on timelines, progress review and other reviews related topics that require further JESP/EFSP discussion- Wayne Beaton

      • David Blevins proposed to skip the Progress review provided that exception clause is documented in the JESP

      • As some concerns were raised we’ll discuss on a later call, once we finish javax namespace discussion

    • PMC update - Ivar Grimstad

Specification document creation

      • We’ll discuss on a later call, once we finish javax namespace discussion

  • TCK process - David Blevins leading the effort

  • Approval of the Meeting minutes

    • Should we approach approvals differently; lazy consensus?

      • We’ll discuss on a later call, once we finish javax namespace discussion

  • Jakarta EE NoSQL provisioning is next step; we are waiting on :

    • Agreements need to be in place (MCCA and WGPA) for project lead/primary committer (Tomitribe)

    • Werner - progress update

--

Tanja Obradovic

Jakarta EE Program Manager | Eclipse Foundation, Inc.

Twitter: @TanjaEclipse

Eclipse Foundation: The Platform for Open Innovation and Collaboration

Back to the top