Bean Validation 3.0 final PR

[starksm64]

Signed-off-by: Scott M Stark starksm64@gmail.com

Include the following in PR#1:

• 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 wombat-spec-x.y.pdf
• Specification HTML in the form of 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 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.
• The URL of the OSSRH staging repository for the api, javadoc:
  https://jakarta.oss.sonatype.org/content/groups/staging/jakarta/validation/jakarta.validation-api/3.0.0/
• The URL of the staging directory on downloads.eclipse.org for the proposed EFTL TCK binary:
  https://download.eclipse.org/ee4j/bean-validation/3.0/beanvalidation-tck-dist-3.0.0.zip
• The URL of the compatibility certification request issue:
  Compatibility certification request for Hibernate Validator for BV 3.0.0 validation-spec#260
  Include the following in PR#2:
• Specification JavaDoc in the wombat/x.y/apidocs directory.

[netlify]

Deploy preview for jakartaee-specifications ready!

Built with commit be3275d

https://deploy-preview-222--jakartaee-specifications.netlify.app

[kwsutter]

@starksm64, a few items to work out... I've embedded some specific comments as part of the code review. And, I also notice that there is Certification Request for the CI posted yet.

I will also post the secondary checklist to help with ensuring that everything is in place for the final ballot. Thanks!

[kwsutter]

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}
• (Optional) Second PR for just apidocs

2. _index.md

• 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/jakarta-{spec}-tck-x.y.z.zip
• 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

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

[kwsutter]

@starksm64 When will these review comments be addressed? Thanks!

[kwsutter]

The _index.md information for the TCK artifacts needs to be updated. Thanks!

[kwsutter]

The TCK SHA 2456 values don't match... I downloaded your TCK here's what I get...

Kevins-MacBook-Pro:Downloads sutter@us.ibm.com$ shasum -a 256 beanvalidation-tck-dist-3.0.0.zip
c975fd229df0c40947a9f0a69b779ec92bebb3d21e05fdc65fccc1d11ef5525b beanvalidation-tck-dist-3.0.0.zip

But, the value specified here and in the certification request is this:
bb0c85c6ab78786b023931cc407e00bbcd96fc26c0d8b56a00c28bc1665c7f01

[dblevins]

Spec committee gives contingent approval upon final review by the mentor, @kwsutter. Kevin will put up for ballot after review.

[kwsutter]

LGTM. Thanks, @starksm64!

[kwsutter]

@starksm64 I found something... Maybe you can answer this...

Your maven coordinates for the API in the _index.md file are these:
https://search.maven.org/artifact/jakarta.bean-validation/jakarta.bean-validation-api/3.0.0/jar

But, bean validation has been using these coordinates (validation instead of bean-validation). There is even a 3.0.0 release already there:
https://search.maven.org/artifact/jakarta.validation/jakarta.validation-api/3.0.0/jar

I know that bean-validation is the official Jakarta EE 9 "short name", but I wanted to verify that you really wanted to make this change.

Also, the final TCK URL in _index.md should be of the form (with jakartaee directory):
https://download.eclipse.org/jakartaee/bean-validation/3.0/beanvalidation-tck-dist-3.0.0.zip

You currently have (with ee4j directory):
http://download.eclipse.org/ee4j/bean-validation/3.0/beanvalidation-tck-dist-3.0.0.zip

Thanks!

[kwsutter]

@starksm64 One more thing...

The SHA 256 value for the TCK needs to be updated on the Certification Request and the TCK Results.

[starksm64]

@starksm64 One more thing...

The SHA 256 value for the TCK needs to be updated on the Certification Request and the TCK Results.

Done

[kwsutter]

@starksm64, any comments on this...

Your maven coordinates for the API in the _index.md file are these:
https://search.maven.org/artifact/jakarta.bean-validation/jakarta.bean-validation-api/3.0.0/jar

But, bean validation has been using these coordinates (validation instead of bean-validation). There is even a 3.0.0 release already there:
https://search.maven.org/artifact/jakarta.validation/jakarta.validation-api/3.0.0/jar

I know that bean-validation is the official Jakarta EE 9 "short name", but I wanted to verify that you really wanted to make this change.

[starksm64]

It has been corrected to:

https://search.maven.org/artifact/jakarta.validation/jakarta.validation-api/3.0.0/jar

[kwsutter]

Need another update, it looks like... Thanks!

[kwsutter]

LGTM. Finally! :-) Thanks, @starksm64

[edbratt]

Please correct this link

[edbratt]

Thank you!

[jeanouii]

Not a big deal, just a question regarding the file name.

There is also a typo

<p>The only changes in Bean Validation 3.0 are changes to support the Jarkarta EE javax to jakarta package namespace change.</p>

Jarkarta instead of Jakarta

Left some minor comments, so want to make sure someone can look at them

[kwsutter]

Not a big deal, just a question regarding the file name.

There is also a typo

<p>The only changes in Bean Validation 3.0 are changes to support the Jarkarta EE javax to jakarta package namespace change.</p>

Jarkarta instead of Jakarta

Good catch, but it's kind of a nit. Especially since this Specification has already passed it's ballot. Go ahead and create an Issue or PR against the BV project to get this corrected in the next update. Thanks.

[kwsutter]

Now that the ballot is complete, there are a few more things to do...

• The specification committee mentor adds this final checklist to the main PR.
• The specification committee member 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
• The specification committee mentor merges the specification (and apidocs) PRs, ensuring the "date:" field in the _index.md file has an appropriate value to allow publishing.
• The specification committee mentor 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.
• The specification project member who created the api staging release promotes the specification api jars to maven central. An example release job script can be found here https://wiki.eclipse.org/MavenReleaseScript.
• The specification committee mentor updates the specification page with the ballot results.
  This list goes on the committed spec index page.
• The specification project team should go through the merged spec website page to verify all the links are valid.
• The specification project team should approve the compatibility request.
• The compatible implementation project/vendor MUST send an email to tck@eclipse.org for approval of the compatible implementation for trademark usage.
• The specification project team should merge any final release branch as appropriate for the branch management for the project.

[kwsutter]

Per our updated process, moving these items to a separate issue against the Spec Project:

• The specification project member who created the api staging release promotes the specification api jars to maven central. An example release job script can be found here https://wiki.eclipse.org/MavenReleaseScript.
• The specification project team should go through the merged spec website page to verify all the links are valid.
• The specification project team should approve the compatibility request.
• The compatible implementation project/vendor MUST send an email to tck@eclipse.org for approval of the compatible implementation for trademark usage.
• The specification project team should merge any final release branch as appropriate for the branch management for the project.