Deliver beanvalidation-spec Specification Version update for Jakarta EE 9

[kwsutter]

Is your feature request related to a problem? Please describe. Jakarta EE 9 is the next major release, with the main focus of moving from the javax namespace to the jakarta namespace.

Describe the solution you'd like This issue will be used to track the progress of this work effort via the Jakarta EE 9 Project board.

Additional context Jakarta EE Specification Process Eclipse Project Handbook Eclipse Release Record for Jakarta EE 9

ToDo

• [x] Create Eclipse Release Record in your respective Jakarta Specification Project. Most Component Release Records will just reference the Jakarta EE 9 Platform Release Plan. But, if your Component deviates at all from the Platform Release Plan, then a description of the changes will be required in the Release Record.
• [x] Initiate a ballot for your Jakarta Release Record/Plan. Again, if your component is only doing the required minimum as defined by the Jakarta EE 9 Platform Release Plan, then no separate ballot is required. You are already approved. But, if your component deviates from the Platform Release Plan, then you will need to initiate your own ballot as defined by the Jakarta EE Specification Process.
• [x] Jakarta-ize your Specification document (if applicable) Many of the Jakarta EE components now have the source for their Specification documents. It is strongly recommended that these Specification documents are properly updated to represent Jakarta EE instead of Java EE. Some helpful instructions are documented here.
• [x] javax -> jakarta Spec updates If your component has Specification source, then all javax package references need to be updated to use jakarta package references.
• [x] javax -> jakarta API updates Your component APIs need to move from using the javax namespace to using the jakarta namespace.
• [x] Release Candidate (RC) of Jakarta API in Maven Central A Release Candidate of your component API should be pushed to Maven Central as soon as humanly possible. This will allow other dependent components to utilize your APIs as they are updating their APIs. Multiple revisions of these Release Candidate APIs are allowed (and probably expected) during the development cycle.
• [x] javax -> jakarta TCK updates Your component TCK needs to be updated to use the jakarta namespace.
• [x] javax -> jakarta Compatible Implementation updates Your compatible implementation that will be used to demonstrate completeness of the Specification needs to be updated to use the jakarta namespace.
• [x] Final Jakarta API available in Staging Repo When ready, your final version of the API needs to be staged to get ready for the PR review and approvals.
• [x] Draft Specification and Apidoc PRs ready for review Like we did for Jakarta EE 8, draft PRs need to be created and reviewed in preparation for the final ballots.
• [x] Release Review Ballot started Each Jakarta EE component will need to initiate a separate Release Review ballot after proper reviewing has completed. To be clear, there will not be a blanket Release Review for all of Jakarta EE 9 like we did for the Plan Review. Each component needs a separate Release Review.

[gsmet]

Hi @kwsutter ,

What's the planned schedule for this?

[kwsutter]

Per the overall Platform Release Plan, June 2020. But, the individual components (ie Bean Validation) would have to be done well before that.

[gunnarmorling]

Hi Kevin,

well before that.

Is there any way to quantify that "well"? That'd really help for our planning here. E.g. is there a timeline for doing candidate releases etc.? Good news is that the BV spec document is (largely, hopefully, anyways) already Jakarta-ized as part of Jakarta EE 8. I don't think we'll have any bandwidth for any actual spec work in terms of new features in the given time frame.

[starksm64]

Is there any way to quantify that "well"?

The following spreadsheet is trying to provide some target timelines: https://docs.google.com/spreadsheets/d/1EN5UEzxFV1Buk7yqdQAweaynWJ3UNn2BjN7blXn9vh4/edit#gid=0

For the early wave specs like BV, 2020-03-20 is the current target for an initial RC release. The vast majority of the EE9 specs will not have any new features as that is the plan. Introducing new features would require a full release plan by the spec project and approval, and this was decided by the platform group to not be what was wanted.

[gunnarmorling]

A random thought just coming to my mind as I was looking at some code: is there already an agreed on namespace for XML descriptors under Jakarta? E.g. BV uses http://xmlns.jcp.org/xml/ns/validation/configuration. Is there something standardized Jakarta pattern already that'd replace that?

[kwsutter]

Not a random thought... We just discussed this on the Platform call this morning. Ivar is working with the Eclipse team to get a proper location for these schemas.

[gunnarmorling]

Excellent, thanks for the heads-up.

[starksm64]

https://projects.eclipse.org/projects/ee4j.bean-validation/releases/3.0

[kwsutter]

Once we get a Milestone or RC API jar file with the Jakarta namespace change, could we get a Notecard inserted into the Milestone/RC column of the Project Board? Since Bean Validation is a Wave 1 deliverable, it would be good to get these available. Thanks!

[starksm64]

Yes, I'm waiting on a permission issue in the CI to get the release out. If I don't get a response soon, I'll do the release and tag by hand since that is what is currently failing.

On Tue, Feb 4, 2020 at 3:46 PM Kevin Sutter notifications@github.com wrote:

Once we get a Milestone or RC API jar file with the Jakarta namespace change, could we get a Notecard inserted into the Milestone/RC column of the Project Board https://github.com/orgs/eclipse-ee4j/projects/17#column-7346435? Since Bean Validation is a Wave 1 deliverable, it would be good to get these available. Thanks!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/eclipse-ee4j/beanvalidation-spec/issues/253?email_source=notifications&email_token=AACRDMXISLU4R72I7JCF3HTRBHO5DA5CNFSM4KGUGQ3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKZJZ2Q#issuecomment-582130922, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACRDMTQGX3KUAY2XKOHDWLRBHO5DANCNFSM4KGUGQ3A .

[starksm64]

I have done a 3.0.0-M1 by tagging the repo outside of the CI environment: https://jakarta.oss.sonatype.org/content/repositories/staging/jakarta/validation/jakarta.validation-api/3.0.0-M1/ It has been release to maven central so should be available soon.

[starksm64]

@gsmet Released an early version of Hibernate Validator that implements BV 3.0.0-M1. https://repo1.maven.org/maven2/org/hibernate/hibernate-validator/7.0.0.Alpha1/