Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deliver batch-api Specification Version update for Jakarta EE 9 #7

Closed
15 tasks done
kwsutter opened this issue Jan 14, 2020 · 7 comments
Closed
15 tasks done

Deliver batch-api Specification Version update for Jakarta EE 9 #7

kwsutter opened this issue Jan 14, 2020 · 7 comments
Assignees
Labels
ee9-release Must-do for Jakarta EE 9 release Epic wave:4

Comments

@kwsutter
Copy link

kwsutter commented Jan 14, 2020

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

  • 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.
  • 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.
  • 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.
  • javax -> jakarta Spec updates
    If your component has Specification source, then all javax package references need to be updated to use jakarta package references.
  • javax -> jakarta API updates
    Your component APIs need to move from using the javax namespace to using the jakarta namespace.
  • 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.
  • Consider generic support - UPDATE: we have rejected this idea and will track post-EE 9 in issue Add generic support: item/checkpoint type for reader/processor/writer/listener classes, plus user data types #13
  • Convert properties and possibly XML targetNamespace in API - issue Migrate JSR 352 references to properties and job XML targetNamespace (if necessary) #12
  • Rename and publish schema (XSD) files - Issue Rename and publish new XSD schema files #21. Pending PR here.
  • javax -> jakarta TCK updates
    Your component TCK needs to be updated to use the jakarta namespace (Java, XML).
    Tracking in the platform TCK and the batch TCK. See also release plan requirements and signature test TODO(s), see here.
  • 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. See also release plan requirements. Maybe consider the update into Glassfish (guessing this is being tracked there but good to follow-up ourselves too).
  • 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.
  • 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.
  • 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.
  • Release jbatch v2.0.0 (and merge into Glassfish as well) once specifications finalize.
@kwsutter
Copy link
Author

@thadumi
Copy link

thadumi commented Mar 14, 2020

Hi, is someone already handling the namespace change for TCK?
If no, I'd like to take care of it.

@scottkurz
Copy link
Contributor

Draft PR started: jakartaee/specifications#238

Waiting for final 3.0.0, 2.0.0 CDI, JTA APIs to be staged to rebuild jbatch impl, TCK, API on these.

@scottkurz
Copy link
Contributor

Ballot has started so I think we're done !

@scottkurz
Copy link
Contributor

Going to reopen with one more item, which is to do a final 2.0 release of the CI: https://github.com/WASdev/standards.jsr352.jbatch/
since we did certification with the 2.0.0-M7 release.

@scottkurz scottkurz reopened this Aug 17, 2020
@scottkurz
Copy link
Contributor

Update: Jakarta Batch 2.0.0 API in Maven Central; final release of jbatch 2.0.0 is still pending delivery of:

  • interceptor 2.0.0
  • transaction api 2.0.0
  • org.glassfish.jaxb.jaxb-runtime 3.0.0

@scottkurz
Copy link
Contributor

Released jbatch 2.0.0 as well and merged into GF via:
eclipse-ee4j/glassfish#23299

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ee9-release Must-do for Jakarta EE 9 release Epic wave:4
Projects
None yet
Development

No branches or pull requests

3 participants