Jakarta Persistence 3.2

[lukasj]

Specification PR template

When creating a specification project release review, create PRs with the content defined as follows.

Include the following in the PR:

• A directory in the form wombat/x.y where x.y is the release major.minor version, and the directory contains the following.
• Specification PDF in the form of jakarta-wombat-spec-x.y.pdf
• Specification HTML in the form of jakarta-wombat-spec-x.y.html
• A specification page named _index.md following the template at:
  https://github.com/jakartaee/specification-committee/blob/master/spec_page_template.md
• For a Progress Review, that sufficient progress has been made on a Compatible Implementation and TCK, to ensure that the spec is implementable and testable.
• For a Release Review, a summary that a Compatible Implementation is complete, passes the TCK, and that the TCK includes sufficient coverage of the specification. The TCK users guide MUST include the instructions to run the compatible implementations used to validate the release.
  Instructions MAY be by reference.
  • Updated release record
  • N/AGenerated IP Log
  • Email to PMC
  • Start release review by emailing EMO
• The URL of the OSSRH staging repository for the api, javadoc:
  https://jakarta.oss.sonatype.org/content/repositories/jakartapersistence-1037/jakarta/persistence/jakarta.persistence-api/3.2.0/
• The URL of the staging directory on downloads.eclipse.org for the proposed EFTL TCK binary:
  https://www.eclipse.org/downloads/download.php?file=/ee4j/jakartaee-tck/jakartaee11/staged/eftl/jakarta-persistence-tck-3.2.0.zip
• The URL of the compatibility certification request issue:
  • Compatibility certification request for EclipseLink 5.0.0-B02 persistence#612
  • Compatibility certification request for Hibernate 7.0.0.Alpha2 persistence#623
• Specification JavaDoc in the wombat/x.y/apidocs directory.
  If desired, an optional second PR can be created to contain just the JavaDoc in the apidocs directory.

Note: If any item does not apply, check it and mark N/A below it.

[netlify]

✅ Deploy Preview for jakartaee-specifications ready!

Name	Link
🔨 Latest commit	0c3b1ac
🔍 Latest deploy log	https://app.netlify.com/sites/jakartaee-specifications/deploys/66372a3c36cd2c00086685c1
😎 Deploy Preview	https://deploy-preview-714--jakartaee-specifications.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[ivargrimstad]

Mentor Spec Review Checklist

1. Spec PR

• PR uses template
• Directory of form {spec}/x.y
• PDF of form jakarta-{spec}-spec-x.y.pdf ("-spec" preferred but not required)
• HTML of form jakarta-{spec}-spec-x.y.html ("-spec" preferred but not required)
• Index page {spec}/x.y/_index.md following template
• Index page {spec}/_index.md following template
• No other files (e.g., no jakarta_ee_logo_schooner_color_stacked_default.png)
• Staging repository link of the form https://jakarta.oss.sonatype.org/content/repositories/staging/jakarta/{spec}/jakarta.{spec}-api/x.y.z/
• EFTL TCK link of the form http://download.eclipse.org/.../+.zip
• Compatibility certification link of the form https://github.com/eclipse-ee4j/{project}/#{issue}
• N/A Second PR for just apidocs

2. _index.md

• Link to project release plan of the form https://projects.eclipse.org/projects/ee4j.{spec}/releases/x.y/plan
• Link to spec pdf
• Link to spec html
• Link to apidocs
• Link to final TCK download zip file of the form https://download.eclipse.org/jakartaee/{spec}/x.y/*{spec}-tck-x.y.z.zip (The folder path is required, the file name pattern is preferred.)
• Link to API jar file of the form https://search.maven.org/artifact/jakarta.{spec}/jakarta.{spec}-api/x.y.z/jar
• Name of and link to at least one Compatible Implementation
• Review summary statement to ensure it has been updated to reflect the work accomplished and does not contain proposal statements as might be found in Plan Review statement.

3. javadocs

• Footer contains Eclipse copyright and link to license
• ESFL license is included, usually as doc-files/speclicense.html
• no META-INF directory in PR
• javadocs-jar artifact matches apidocs (optional for this release)

4. Spec PDF

• Correct spec title
• Version number of the form x.y, not x.y.z
• Correct Eclipse copyright line
• No DRAFT or SNAPSHOT
• Correct Logo

5. Spec HTML

• Same as PDF

6. TCK zip file

• README file (optional for this release)
• EFTL license file, preferably named LICENSE.md
• User's Guide (or equivalent documentation)
• How to test the Compatible Implementation(s) listed in _index.md above with the TCK (may be in UG)

7. TCK User's Guide (or equivalent documentation)

• Software requirements listed
• Installation and configuration described
• How to run tests
• Where to file challenges

8. Compatibility certification request

• Request follows template
• SHA-256 fingerprint matches staged TCK zip file
• Request issue has certification label.

9. TCK results summary

• Page is hosted by Compatible Implementation project
• Includes all information from certification request
• Summary includes number of tests passed, failed, errors
• SHA-256 fingerprint matches staged TCK zip file on cert request

10. If a Release Review is required, the specification project team contacts the EMO to initiate the review by sending an email to emo@eclipse.org.
    (A Release Review is not required if the current release is a Service Release based on a previously successful Major or Minor
    release as indicated by a release record on the project's Releases page, e.g., the Jakarta Servlet releases page.)

    • An issue will be created by the EMO to track the release review.
    • The specification project team requests approval for the release from the PMC by sending an email to ee4j-pmc@eclipse.org.
    • The specification project team then delivers an IP Log to the IP Team for their review as described in https://www.eclipse.org/projects/handbook/#pmi-commands-iplog.

11. Update Jakarta EE API jar

• Update the Jakarta EE API jar by submitting a PR to the jakartaee-api project that updates the version number of your API jar file.

[lukasj]

CCR along with CI are pending, the rest is ready/completed

[mtdelgadoa]

EMO REVIEW CHECKLIST

EDP Review status: COMPLETED

EMO review checklist

PMI record: https://projects.eclipse.org/projects/ee4j.jpa/reviews/3.2-release-review

EF Specification Process

• Spec Committee Ballot completed

Intellectual Property Management

• All project code has copyright and license headers correctly applied. ** EMO will scan the code at their discretion **
• All distributed third-party content has been vetted by the IP Due Diligence process (i.e., IP Log has been approved)

Open Source Rules of Engagement

• PMC approval on the mailing list

General:

• Project is operating within the mission and scope defined in its top-level project’s charter
• Project is operating within the bounds of its own scope
• Project is operating in an open and transparent manner
• Overall the project is operating according to the Eclipse Development Process.

Things to check:

• Communication channels advertised
• Advertised communication channels used
• Committers are responding to questions
• Committers are responding to issues
• Committers are responding to pull/merge/review requests

Branding and Trademarks
The following applies when the project has a custom website.
To the best of our knowledge:

• Project content correctly uses Eclipse Foundation trademarks
• Project content (code and documentation) does not violate trademarks owned by other organizations

Things to check:

• Project website uses the project's formal name in first and all prominent references
• Project website includes a trademark attribution statement
• Project website footers contain all necessary elements

Legal Documentation
Required files:

• License files in all repository roots
• README
• CONTRIBUTING (or equivalent)

Recommended files:

• NOTICES or equivalent (you can use the Legal Documentation generator available under committer tools)
• CODE_OF_CONDUCT
• SECURITY

See examples for Security file and Code of Conduct.

Required elements:

• ECA is referenced/described

Recommended elements:

• Build instructions provided
• Security policy is described

Metadata (PMI)

• The formal name, e.g. "Eclipse Foo™", is used in the project title
• The formal name including appropriate marks (e.g, "™") is used in the first mention in the text of the project description, and scope
• The project description starts with a single paragraph that can serve as an executive summary
• Source code repository references are up-to-date
• Download links and information are up-to-date (see EF handbook for more information on how-to do this)
• Communication channels listed in the PMI (i.e. public mailing list, forums, etc.)

[lukasj]

added CCR, so I'm done here, I hope..

[ivargrimstad]

Everything looks great! Thanks @lukasj!
I will hold off starting the ballot until Friday to see if a CCR for Hibernate ORM comes in as well.

[beikov]

Hibernate ORM is in the process of certifying. I don't think there are any spec changes/fixes necessary, but we found some problems in the TCK. There may be more, so we might create further PRs. I guess you need a final TCK version before publishing the spec as well?

[ivargrimstad]

Hibernate ORM is in the process of certifying. I don't think there are any spec changes/fixes necessary, but we found some problems in the TCK. There may be more, so we might create further PRs. I guess you need a final TCK version before publishing the spec as well?

Are these changes to be considered as challenges to the TCK? Or are the changes of a kind that will invalidate the CCR for EclipseLink?

[beikov]

Since we might request changes to the TCK, I would say that they "could" invalidate the CCR for EclipseLink.

[ivargrimstad]

Since we might request changes to the TCK, I would say that they "could" invalidate the CCR for EclipseLink.

Yes, that is my question: Are the changes of a such nature that they are covered by the challenge process?
WDYT @lukasj

[beikov]

Here are some further changes that improve the testing experience significantly: jakartaee/platform-tck#1291

[lukasj]

Are these changes to be considered as challenges to the TCK?

my understanding is that as long as the ballot as such is not started, updates can be done without going through the challenge process and can be considered as dev-updates/regular bug fixes as long as the mentor and reviewer of this PR is fine with these changes and accepts a bit of additional work

Or are the changes of a kind that will invalidate the CCR for EclipseLink?

from EL point of view, changes are OK, TCK was rebuilt, restaged, API and EL has been retested, CCR has been updated (see actual results) and everything was synced

[lukasj]

Here are some further changes that improve the testing experience significantly: jakartaee/platform-tck#1291

I do not consider this as important as the previous PR, but I'll leave it up to @ivargrimstad to say yes/no in this case. I have no problem with it from EL side and an argument to accept it now is that this particular change does not seem to fall under the challenge category, so it may be difficult to smuggle it in later as the challenge process does not allow this kind of changes

[ivargrimstad]

Here are some further changes that improve the testing experience significantly: jakartaee/platform-tck#1291

I do not consider this as important as the previous PR, but I'll leave it up to @ivargrimstad to say yes/no in this case. I have no problem with it from EL side and an argument to accept it now is that this particular change does not seem to fall under the challenge category, so it may be difficult to smuggle it in later as the challenge process does not allow this kind of changes

It is entirely up to the Persistence project team. I am ready to start the ballot any time now, but when I do so, you can not make any more changes to the artifacts. Let me know if you want to make this change. Then I will hold off on starting the ballot until it is done.

[lukasj]

It is entirely up to the Persistence project team. I am ready to start the ballot any time now, but when I do so, you can not make any more changes to the artifacts. Let me know if you want to make this change. Then I will hold off on starting the ballot until it is done.

yes, we want. We also want to have Hibernate among ratifying implementations - what is the deadline for that? Can we afford waiting for that?

[ivargrimstad]

It is entirely up to the Persistence project team. I am ready to start the ballot any time now, but when I do so, you can not make any more changes to the artifacts. Let me know if you want to make this change. Then I will hold off on starting the ballot until it is done.

yes, we want. We also want to have Hibernate among ratifying implementations - what is the deadline for that? Can we afford waiting for that?

The sooner, the better. Can you get it done by the beginning of next week?

[lukasj]

@beikov TCK has been refreshed, EclipseLink has been re-tested, CCR updated. Now it's your turn ;-)

[beikov]

Thanks. We're working on it :)
I hope we can finish this today since tomorrow is a holiday for most of our team

[sebersole]

We are working on investigating a few remaining failures in our TCK run. We should be able to release a passing implementation and complete the certification request this week for sure; hopefully tomorrow - I am not in Europe :)

[ivargrimstad]

We are working on investigating a few remaining failures in our TCK run. We should be able to release a passing implementation and complete the certification request this week for sure; hopefully tomorrow - I am not in Europe :)

Great! I will hold off starting the release review until Friday, or when you're done, whichever comes first

[ivargrimstad]

@lukasj Hibernate has now filed a CCR. I have added the link in the PR comment. Can you add Hibernate to the list of Compatible implementations in the _index.md page?

[lukasj]

@lukasj Hibernate has now filed a CCR. I have added the link in the PR comment. Can you add Hibernate to the list of Compatible implementations in the _index.md page?

@ivargrimstad added

[ivargrimstad]

• On ballot completion, the specification committee mentor:

• adds this final checklist to the main PR.
• adds the approved label to the PRs, and sends out the Ballot Summary per this template to the public Jakarta EE Specification Committee email list
• calculates the staged EFTL TCK signature and promotes it to the committee download area
  using the https://ci.eclipse.org/jakartaee-spec-committee/job/promote-release/ job. Manually editing the jenkins Build Information will help identify the build (ie. Mail 2.0 or CDI 3.0).
• merges the specification (and apidocs) PRs, ensuring the "date:" field in the _index.md file has an appropriate value to allow publishing.
• updates the specification page with the ballot results. This is normally done via a separate PR that should be reviewed, approved, and merged.
• notifies the EMO of the ballot results by email to emo@eclipse-foundation.org. Just forward the ballot summary note sent earlier to the public Spec Committee email list.
• creates an issue in the specification project that includes the following checklist for the specification project team:
  Finalize the Jakarta Persistence 3.2 Release persistence#630