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

Jakarta Faces 4.1 #738

Merged
merged 9 commits into from
Jun 5, 2024
Merged

Jakarta Faces 4.1 #738

merged 9 commits into from
Jun 5, 2024

Conversation

arjantijms
Copy link
Contributor

@arjantijms arjantijms commented May 7, 2024

Specification PR template

When creating a specification project release review, create PRs with the content defined as follows.

Include the following in the PR:

Note: If any item does not apply, check it and mark N/A below it.

Signed-off-by: Arjan Tijms <[email protected]>
Copy link

netlify bot commented May 7, 2024

Deploy Preview for jakartaee-specifications ready!

Name Link
🔨 Latest commit 33d4b59
🔍 Latest deploy log https://app.netlify.com/sites/jakartaee-specifications/deploys/665fcd1c6e5f7d00085540e0
😎 Deploy Preview https://deploy-preview-738--jakartaee-specifications.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@ivargrimstad ivargrimstad added the release review Use this label on PRs that are filed for release review label May 9, 2024
@mtdelgadoa
Copy link

mtdelgadoa commented May 13, 2024

Hello all,
the EMO is trying to avoid duplication of release records, so we will be providing our feedback and comments related to this release directly here.

EMO REVIEW CHECKLIST

EDP Review status: Completed

EMO review checklist

PMI record: URL

EF Specification Process

  • 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 **
  • 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

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:

  • Project content correctly uses Eclipse Foundation trademarks
  • Project content (code and documentation) does not violate trademarks owned by other organizations

Things to check:

  • Project website uses the project's formal name in first and all prominent references
  • Project website includes a trademark attribution statement
  • Project website footers contain all necessary elements

Legal Documentation
Required files:

  • License files in all repository roots
  • README
  • CONTRIBUTING (or equivalent)

Recommended files:

See examples for Security file and Code of Conduct.

Required elements:

  • ECA is referenced/described

Recommended elements:

Metadata (PMI)

  • The formal name, e.g. "Eclipse Foo™", is used in the project title
  • The formal name including appropriate marks (e.g, "™") is used in the first mention in the text of the project description, and scope
  • The project description starts with a single paragraph that can serve as an executive summary
  • 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)
  • Communication channels listed in the PMI (i.e. public mailing list, forums, etc.)

@kazumura
Copy link
Contributor

kazumura commented May 14, 2024

Mentor Spec Review Checklist

  1. Spec PR
  1. _index.md
  1. 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)
  1. 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
  1. Spec HTML
  • Same as PDF
  1. 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)
  1. TCK User's Guide (or equivalent documentation)
  • Software requirements listed
  • Installation and configuration described
  • How to run tests
  • Where to file challenges
  1. Compatibility certification request
  • Request follows template
  • SHA-256 fingerprint matches staged TCK zip file
  • Request issue has certification label.
  1. 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
  1. 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.)

    • The specification project team requests approval by sending an email to the EMO (with cc to the PMC) that contains a link to this PR and a request to the PMC for approval.
  2. Update Jakarta EE API jar

  • 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.

@arjantijms
Copy link
Contributor Author

@kazumura CCR has been added

@kazumura
Copy link
Contributor

@arjantijms
Thanks for PR.

The followings are missing in this PR. Please add them.

  • Jsdoc
  • Renderkitdoc
  • VDLDoc

@arjantijms
Copy link
Contributor Author

The followings are missing in this PR. Please add them.

Thanks, it is done!

@kazumura kazumura added final Ready for Vote ballot Delivered to the Specification Committee for ballot labels May 21, 2024
@pnicolucci
Copy link
Contributor

Hi, the _index.md should be updated to reflect the changes for Faces 4.1.

We should call out the changes from the Faces 4.1 Changelog.

These are Faces 5.0 changes that should be removed:

  1. Make SelectItem#value generic faces#206 (Make SelectItem#value generic Component: Components/Renderers)
  2. Clarify EL / CDI integration: implicit object or CDI producer for artifacts without required inject point support (request, session, component, cc) faces#1564 looks to be mentioned: Re-add #{request} in CDI mode
  3. Clarify EL / CDI integration: implicit object or CDI producer for artifacts without required inject point support (request, session, component, cc) faces#1564 looks to be mentioned: Re-add #{request} in CDI mode

Missing Deprecation:

  1. Missing Full State Saving Deprecation in the deprecations list: Faces 4.1: Deprecate full state saving (FSS) faces#1829

Other:

  1. I don't think there is a need to call out: Remove unused PreDestroyCustomScopeEvent and PostConstructCustomScopeEventAdd in both the new features and removals.

@arjantijms
Copy link
Contributor Author

Hi, the _index.md should be updated to reflect the changes for Faces 4.1.

Thanks, can you verify the updated index?

@pnicolucci
Copy link
Contributor

Hi @arjantijms

We should remove the following as they point to Faces 5.0 work:

  1. "importConstants should be allowed everywhere, not only in f:metadata" as that is in Faces 5.0: importConstants should be allowed everywhere, not only in f:metadata faces#1466
  2. "Enhance UIInput events with HTML5 like oninput" as that is also Faces 5.0: Enhance UIInput events with HTML5 like oninput faces#1507
  3. Setting/overriding components default value -> Setting/overriding components default value faces#1602

Also I think removing "<f:ajax> execute="@this" and render="@this" does not behave as expected when nested in composite component" would be good since that looks like it was for Faces 4.0: jakartaee/faces#1567

Would be good to add:

Add UUIDConverter -> jakartaee/faces#1819
Add ExternalContext.setResponseContentLengthLong -> jakartaee/faces#1764
Add rowStatePreserved property to UIRepeat, exactly the same as UIData -> jakartaee/faces#1263
Spec: jakarta.faces.FACELETS_REFRESH_PERIOD default when ProjectStage is Development -> jakartaee/faces#1821
FacesMessage: implement equals(), hashcode(), toString() -> jakartaee/faces#1823

Copy link
Contributor

@Pandrex247 Pandrex247 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple of things

faces/4.1/_index.md Outdated Show resolved Hide resolved
faces/4.1/_index.md Show resolved Hide resolved
arjantijms and others added 2 commits May 28, 2024 12:35
Co-authored-by: Andrew Pielage <[email protected]>
Co-authored-by: Andrew Pielage <[email protected]>
@kazumura
Copy link
Contributor

kazumura commented Jun 3, 2024

@arjantijms
Please look into @pnicolucci comment at "#738 (comment)" .

@arjantijms
Copy link
Contributor Author

Please look into @pnicolucci comment at "#738 (comment)" .

I just did, thanks! @pnicolucci can you do the final check?

@pnicolucci
Copy link
Contributor

@arjantijms this looks good! My only minor comment is that the UUID entry points to an issue but nothing else does. So for consistency, we could remove the issue reference, or add an issue for each item.

@kazumura kazumura added approved The ballot was approved by the Specification Committee and removed ballot Delivered to the Specification Committee for ballot labels Jun 5, 2024
@kazumura
Copy link
Contributor

kazumura commented Jun 5, 2024

On ballot completion, the specification committee mentor:

  • adds this final checklist to the main PR.
  • 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
  • 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).
  • merges the specification (and apidocs) PRs, ensuring the "date:" field in the _index.md file has an appropriate value to allow publishing.
  • updates the specification page with the ballot results. This is normally done via a separate PR that should be reviewed, approved, and merged.
  • 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.
  • creates an issue in the specification project that includes the following checklist for the specification project team: Finalize the Jakarta Faces 4.1 Release faces#1930

@kazumura kazumura merged commit 703102d into jakartaee:master Jun 5, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved The ballot was approved by the Specification Committee final Ready for Vote release review Use this label on PRs that are filed for release review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants