Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "How to Prepare API Projects to Jakarta EE 8 Release"
| Line 11: | Line 11: | ||
#* Javadocs should include the [https://raw.githubusercontent.com/eclipse-ee4j/jakartaee-api/master/licenses/EFSL.html Eclipse Foundation Specification License]. | #* Javadocs should include the [https://raw.githubusercontent.com/eclipse-ee4j/jakartaee-api/master/licenses/EFSL.html Eclipse Foundation Specification License]. | ||
#* Version in pom.xml should be increased by 0.0.1 comparing to the previously released API artifact | #* Version in pom.xml should be increased by 0.0.1 comparing to the previously released API artifact | ||
| + | #* GAVs should remain as used in the Glassfish 5.1 release. They should not be updated for changes in the project names. That will be addressed post Jakarta EE 8. | ||
# Generate Stand-alone TCK test results. Use version staged on the previous step. There are some ways how to do it. Teams are free to choose any of them: | # Generate Stand-alone TCK test results. Use version staged on the previous step. There are some ways how to do it. Teams are free to choose any of them: | ||
## Create custom TCK test job | ## Create custom TCK test job | ||
Revision as of 18:45, 12 July 2019
- Scan and make the following changes in javadocs and all text files such as (README.md, NOTICE.md, CONTRIBUTION.md, etc) in a repository
- Update project name as it listed on Eclipse project page (ex. Jakarta JSON Binding)
- Update acronyms, use new acronyms, approved by a spec committee (see guideline here).
- Update references to other specifications with their new names
- Remove references to JCP process or replace them with references to JESP.
- Example: JSR-367 -> Jakarta JSON Binding
- Generate the "boilerplate" specification document, using the instructions and recommendations provided in the Steering Committee guidance (The document is still under Steering Committee review, but projects are free to take the recommended actions immediately).
- Use the same spec version number as the previously released spec
- Make a staging release of API JAR from the revised source code.
- Source code should use the new specification names and follow the acronym guidelines, and should remove any JSR references.
- Javadocs should include the Eclipse Foundation Specification License.
- Version in pom.xml should be increased by 0.0.1 comparing to the previously released API artifact
- GAVs should remain as used in the Glassfish 5.1 release. They should not be updated for changes in the project names. That will be addressed post Jakarta EE 8.
- Generate Stand-alone TCK test results. Use version staged on the previous step. There are some ways how to do it. Teams are free to choose any of them:
- Create custom TCK test job
- Guidance is here.
- Save the test results when all tests succeed.
- Manually run TCK by whatever means the project has used in the past. Save results when all tests succeed.
- Create custom TCK test job
- When tests are passed submit for ballot
- Specification Document from (2) above
- Final TCK test bundle
- Final version of standalone TCK bundles will be uploaded to Eclipse downloads
- Final JavaDocs (from 3)
- When approved
- Release staged artifacts to Maven Central
- If (5) is accomplished prior to Ballot submission deadline (currently July 15) and Eclipse has released specification text to your project -- please feel free to start to generate a more detailed Jakarta EE specification, from the contributed specification text.