Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakarta.ee-spec.committee] jarkata.ee and spec committee repo requirements

To reiterate what we discussed today as requirements to support the spec committee’s ratifying of final specifications based on what we have discussed over the past two weeks:

1. We will use the jakarta.ee spec prototype that Wayne created to support the initial version of a jcp.org analog where each specification has a root page with release information, drill down to release artifacts, votes, etc. The release artifacts will be bundled by value in the release section with the exception of the EFTL TCK, which will be referenced via a link to version that has been signed by the spec committee GPG key.
2. We need a spec committee GitHub repo that will host the spec milestones and final releases. When a spec requests ratification of a release, they create a PR against the spec committee repository with the update to the spec page content. We will have a template directory that project can use as the starting point for obtaining the starting point for creating release content.
3. The spec committee needs a JIPP to manage the signing of the EFTL TCKs. As part of ratifying a final release the spec committee will take the EFTL binary from the spec project download area on download.eclipse.org and sign it using the GPG key assigned tot he spec committee. This is similar to what spec projects do when signing artifacts for release to maven central. This will require conventions for the names of the spec download directories, and versioned binary name as I expect the Jenkins job will be a parameterized build where one selects the spec project short name from a drop down, and then the location of the TCK binary falls out, and the signed EFTL binary is promoted to a similar location under the spec committee download directory. For example,

+ ee4j/
    + jakarta-servlet/
        + 1.0.1/
            - jakarta-servlet-tck.zip
            - jakarta-servlet-spec.pdf
            - jakarta-servlet-spec-html.zip
    + jakartaee-spec/
        + jakarta-servlet/
            + 1.0.1/
               - jakarta-servlet-tck.zip
               - jakarta-servlet-tck.zip.asc


Right now I see links for a jakartaee-tck build like the following:

So we may need both a spec and a tck base name associated with the project short name (jakartaee-platform, jakartaee-tck) if for example both the spec and tck were signed and promoted to a jakartaee-spec. We just need to agree on a common naming convention so that the jakarta.ee spec template pages and spec committee Jenkins job can have a consistent parameterized setup to work with every spec project.


Back to the top