Jakarta Server Pages 4.0.0
Specification PR template
When creating a specification project release review, create PRs with the content defined as follows.
Include the following in the PR:
- [X] A directory in the form wombat/x.y where x.y is the release major.minor version, and the directory contains the following.
- [x] Specification PDF in the form of jakarta-wombat-spec-x.y.pdf
- [x] Specification HTML in the form of jakarta-wombat-spec-x.y.html
- [x] A specification page named _index.md following the template at: https://github.com/jakartaee/specification-committee/blob/master/spec_page_template.md
- [X] 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.
- [x] Updated release record
- ~[ ] Generated IP Log~ no longer required according to project handbook
- [x] Email to PMC
- [x] Start release review by emailing EMO
- [X] The URL of the OSSRH staging repository for the api, javadoc: https://jakarta.oss.sonatype.org/content/repositories/jakartaservletjsp-1030
- [X] The URL of the staging directory on downloads.eclipse.org for the proposed EFTL TCK binary: https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee11/staged/eftl/
- [X] The URL of the compatibility certification request issue: https://github.com/jakartaee/pages/issues/265
- [x] 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
apidocsdirectory.
Note: If any item does not apply, check it and mark N/A below it.
This is an initial draft. Everything is complete and ready for the release review - I just need to ensure everything is staged to the right place and complete the paperwork.
Deploy Preview for jakartaee-specifications ready!
| Name | Link |
|---|---|
| Latest commit | d3f9881f01bc64a92281281b9b3756c952e6c4a1 |
| Latest deploy log | https://app.netlify.com/sites/jakartaee-specifications/deploys/6658a50c7ed49e0008621ac3 |
| Deploy Preview | https://deploy-preview-723--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.
@markt-asf The TCK https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee11/staged/eftl/jakarta-pages-tck-4.0.0.zip was the one created from platform tck project before the migration of the Server Pages TCK.
I would like to remove this old version once a new Jenkins job from https://ci.eclipse.org/jsp builds and copies a TCK bundle at https://download.eclipse.org/ee4j/pages/ using the instructions given at https://github.com/jakartaee/pages/pull/261#issuecomment-2026751030. Please let me know if you are facing any issue with this.
Note: The TCK being used still has SNAPSHOT dependencies. This review should not progress until an updated TCK is available without SNAPSHOT dependencies.
Mentor Spec Review Checklist
- Spec PR
- [x] PR uses template
- [x] Directory of form {spec}/x.y
- [x] PDF of form jakarta-{spec}-spec-x.y.pdf ("-spec" preferred but not required)
- [x] HTML of form jakarta-{spec}-spec-x.y.html ("-spec" preferred but not required)
- [x] Index page {spec}/x.y/_index.md following template
- [x] Index page {spec}/_index.md following template
- [x] No other files (e.g., no jakarta_ee_logo_schooner_color_stacked_default.png)
- [x] Staging repository link of the form https://jakarta.oss.sonatype.org/content/repositories/staging/jakarta/{spec}/jakarta.{spec}-api/x.y.z/
- [x] EFTL TCK link of the form http://download.eclipse.org/.../+.zip
- [x] Compatibility certification link of the form https://github.com/eclipse-ee4j/{project}/#{issue}
- [x] N/A (Optional) Second PR for just apidocs
- _index.md
- [x] Link to project release plan of the form https://projects.eclipse.org/projects/ee4j.{spec}/releases/x.y/plan
- [x] Link to spec pdf
- [x] Link to spec html
- [x] Link to apidocs
- [x] 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.)
- [x] Link to API jar file of the form https://search.maven.org/artifact/jakarta.{spec}/jakarta.{spec}-api/x.y.z/jar
- [x] Name of and link to at least one Compatible Implementation
- [x] 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.
- javadocs
- [x] Footer contains Eclipse copyright and link to license
- [x] ESFL license is included, usually as doc-files/speclicense.html
- [x] no META-INF directory in PR
- [x] javadocs-jar artifact matches apidocs (optional for this release)
- Spec PDF
- [x] Correct spec title
- [x] Version number of the form x.y, not x.y.z
- [x] Correct Eclipse copyright line
- [x] No DRAFT or SNAPSHOT
- [x] Correct Logo
- Spec HTML
- [x] Same as PDF
- TCK zip file
- [x] README file (optional for this release)
- [x] EFTL license file, preferably named LICENSE.md
- [x] User's Guide (or equivalent documentation)
- [x] How to test the Compatible Implementation(s) listed in _index.md above with the TCK (may be in UG)
- TCK User's Guide (or equivalent documentation)
- [x] Software requirements listed
- [x] Installation and configuration described
- [x] How to run tests
- [x] Where to file challenges
- Compatibility certification request
- [x] Request follows template
- [x] SHA-256 fingerprint matches staged TCK zip file
- [x] Request issue has
certificationlabel.
- TCK results summary
- [x] Page is hosted by Compatible Implementation project
- [x] Includes all information from certification request
- [x] Summary includes number of tests passed, failed, errors
- [x] SHA-256 fingerprint matches staged TCK zip file on cert request
-
If a Release Review is required, the specification project team contacts the EMO to initiate the review by sending an email to [email protected]. (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.)
- [x] An issue will be created by the EMO to track the release review.
- [x] The specification project team requests approval for the release from the PMC by sending an email to [email protected].
- [x] 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.
-
Update Jakarta EE API jar
- [x] 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.
EMO REVIEW CHECKLIST
EDP Review status: COMPLETED
EMO review checklist
PMI record: URL
EF Specification Process
- [x] 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 **
- [x] 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
- [x] 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:
- [x] Project content correctly uses Eclipse Foundation trademarks
- [x] Project content (code and documentation) does not violate trademarks owned by other organizations
Things to check:
- [x] Project website uses the project's formal name in first and all prominent references
- [x] Project website includes a trademark attribution statement
- [x] Project website footers contain all necessary elements
Legal Documentation Required files:
- [x] License files in all repository roots
- [x] README
- [x] CONTRIBUTING (or equivalent)
Recommended files:
- [x] NOTICES or equivalent (you can use the Legal Documentation generator available under committer tools)
- [x] CODE_OF_CONDUCT
- [ ] SECURITY
See examples for Security file and Code of Conduct.
Required elements:
- [x] ECA is referenced/described
Recommended elements:
- [ ] Build instructions provided
- [ ] Security policy is described
Metadata (PMI)
- [x] The formal name, e.g. "Eclipse Foo™", is used in the project title
- [x] The formal name including appropriate marks (e.g, "™") is used in the first mention in the text of the project description, and scope
- [x] The project description starts with a single paragraph that can serve as an executive summary
- [x] 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)
- [x] Communication channels listed in the PMI (i.e. public mailing list, forums, etc.)
Note: The TCK being used still has SNAPSHOT dependencies. This review should not progress until an updated TCK is available without SNAPSHOT dependencies.
I have updated the TCK at https://www.eclipse.org/downloads/download.php?file=/ee4j/jakartaee-tck/jakartaee11/staged/eftl/jakarta-pages-tck-4.0.0.zip to remove the SNAPSHOT dependencies for now. This was built using the Jenkins job https://ci.eclipse.org/jakartaee-tck/job/11/job/standalone-tck/job/eftl-pages-standalonetck-build_from_pages_project/ using TCK sources from jakartaee/pages/tck .
@markt-asf @ivargrimstad @arjantijms I could not find a Compatibility certification link under https://github.com/eclipse-ee4j/wasp/issues, since Tomcat 11 is mentioned as the compatible implementation, could that be outside Eclipse?
@markt-asf @ivargrimstad There is the name "Apache Tomcat 11.0.0-M19-SNAPSHOT" of a compatible implementation in the _index.md, but no link, is that good enough?
@markt-asf About the javadocs, was there a reason to stick with "Copyright © 2018, 2021 Eclipse Foundation." in the footer instead of "Copyright (c) 2018, 2024 Eclipse Foundation." like the spec documents?
@markt-asf @ivargrimstad @arjantijms I could not find a Compatibility certification link under https://github.com/eclipse-ee4j/wasp/issues, since Tomcat 11 is mentioned as the compatible implementation, could that be outside Eclipse?
It's perfectly fine that an implementation outside eclipse ratifies as the compatible implementation.
WaSP will certify at a later date.
@markt-asf @ivargrimstad @arjantijms I could not find a Compatibility certification link under https://github.com/eclipse-ee4j/wasp/issues, since Tomcat 11 is mentioned as the compatible implementation, could that be outside Eclipse?
It's perfectly fine that an implementation outside eclipse ratifies as the compatible implementation.
WaSP will certify at a later date.
Yes, the more implementations the merrier!
@markt-asf @ivargrimstad There is the name "Apache Tomcat 11.0.0-M19-SNAPSHOT" of a compatible implementation in the
_index.md, but no link, is that good enough?
There should be a link to a location where it is possible to download the implementation
Progressing the PR will require an updated Pages TCK to be staged. The current one has a missing dependency. It is also using unexpected Maven coordinates.
If I hack my way around the issues with the Pages TCK then the tests all pass so I should be able to progress this PR quickly once an updated TCK is available.
Ah. The Pages TCK has been transferred to the Pages project. That essentially means I am going to have to figure out how to fix this (it looks as if it is already fixed) and how to stage an updated TCK (may not be quite so easy). Not sure how long any of this is going to take.
Since it is a relatively small change to hack around the TCK issues (add a dependency, change Maven coordinates) we could proceed with the 2024-04-16 version of the TCK. The main thing I don't like about that is that the finally released TCK will be wrong.
I am going to see if I can get a fixed version of the TCK staged. If that looks to be taking too long, the fallback will be to use the 2024-04-16 version and hack around the issues.
With some much appreciated help from @arjantijms, I have been able to stage the updated Pages TCK via Jenkins. There are still some niggles to be ironed out but I am confident I'll be able to address those quickly. I expect to be able to stage the final Pages JCK, re-stage the Pages API with the copyright fix for the API docs and provided an updated CCR using Tomcat 11.0.0-M20 by the end of today.
With some much appreciated help from @arjantijms, I have been able to stage the updated Pages TCK via Jenkins. There are still some niggles to be ironed out but I am confident I'll be able to address those quickly. I expect to be able to stage the final Pages JCK, re-stage the Pages API with the copyright fix for the API docs and provided an updated CCR using Tomcat 11.0.0-M20 by the end of today.
@markt-asf I see a staged version of pages tck at https://download.eclipse.org/ee4j/pages/jakartaee11/staged/eftl/ . It does not have userguide in docs/ folder.
The userguide need to be built separately before the tck bundle.
cd $WORKSPACE/tck/docs; mvn to be run before cd $WORKSPACE/tck; mvn clean install
@alwin-joseph Thanks. User guide should be fixed now and I expect the mirrors will pick up the new version fairly quickly.
I think that is all the requested changes completed. Pages 4.0.0 is (hopefully) ready for the release ballot now.
There are two Plan Review section in the pages/4.0/_index.md. One line needs to be removed (line 42 and line 44)
Plan Review
@markt-asf it would be nice to specifically call out Remove the deprecated JspException.getRootCause in the removals/deprecations section. Currently listed in the change log: https://github.com/jakartaee/pages/blob/master/spec/src/main/asciidoc/ServerPages.adoc#c1-changes-between-jsp-40-and-jsp-31
On ballot completion, the specification committee mentor (@keilw):
- [x] adds this final checklist to the main PR.
- [x] adds the
approvedlabel to the PRs, and sends out the Ballot Summary per this template to the public Jakarta EE Specification Committee email list - [x] 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).
- [x] merges the specification (and apidocs) PRs, ensuring the "date:" field in the _index.md file has an appropriate value to allow publishing.
- [x] updates the specification page with the ballot results. This is normally done via a separate PR that should be reviewed, approved, and merged.
- [x] notifies the EMO of the ballot results by email to [email protected]. Just forward the ballot summary note sent earlier to the public Spec Committee email list.
- [x] creates an issue in the specification project that includes the following checklist for the specification project team: https://github.com/jakartaee/pages/issues/272