Jakarta XML Binding 4.0 Plan Review

[lukasj]

Signed-off-by: Lukas Jungmann lukas.jungmann@oracle.com

Plan Review PR template

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

Include the following in the PR:

• A directory in the form wombat/x.y where x.y is the release major.minor version.
• An index page wombat/x.y/_index.md following template
• Title should be on the form "Jakarta Wombat X.Y (under development)"
• Includes a plan for the release. Usually, a couple of statements is enough. Otherwise, a link to a document describing the release.
• N/A - Includes a detailed description of any backward incompatibility (Mark with N/A and check if none)
• N/A - Declares optional features if there are any (Mark with N/A and check if none)
• Includes minimum Java SE version
• N/A - Describe any updates or required changes including splitting out the TCK (Mark with N/A and check if not planned)
• Link to updated release record
  https://projects.eclipse.org/projects/ee4j.jaxb/releases/4.0

[netlify]

✔️ Deploy Preview for jakartaee-specifications ready!

🔨 Explore the source changes: fde623a

🔍 Inspect the deploy log: https://app.netlify.com/sites/jakartaee-specifications/deploys/60b90dfe6f6dd60008f806f8

😎 Browse the preview: https://deploy-preview-357--jakartaee-specifications.netlify.app

[marceloancelmo]

LGTM
I will initiate the ballot soon

[kwsutter]

I would like to see an explicit statement regarding the required major version update. I know we've discussed this on other Plan Reviews, but it would be good to explain the specific reason in this JAXB update. Thanks!

[lukasj]

@kwsutter Dropping support for JAXB 1 related APIs/functionality (ie validation) as well as dropping explicit dependency on JavaBeans Framework are both removals, thus backward incompatible changes requiring major version change - both are explicitly mentioned (and both also fall under requirements from other specs, in this case xml-ws). Or do youmean sth else?

[kwsutter]

@lukasj Those are the type of changes I was referring to. I was just looking for something more explicit in the text of the release plans to indicate that. For example, something along these lines:

• drop explicit dependency on JavaBeans (Has transitive relationship to any dependent specifications. Removal of JavaBeans is a breaking API change.)
• editorial updates, clarifications and removal of JAXB 1 from the specification (May have transitive relationship to any dependent specifications. Removal of JAXB 1 is a breaking API change.)

Just something to allow the casual reader to understand why a major version upgrade was necessary. I know it's very natural for you and others more intimate with JAXB, but for others, it helps identify the reasons for the major version update. Thanks!

[lukasj]

is it allowed to change the PR while the ballot is in progress? since it seems to be required to explicitly list bkwd incompatibilities now in the plan, does it mean that updating the same entry in the release record - probably before release review - is not/won't be required to avoid duplications or is the expectation that both should be kept in sync?

[kwsutter]

In this case, you are just further clarifying your intent of the Release Plan. You're not modifying what was going to be included. You are just explaining that these proposed changes are the reason behind the major version update. That is an okay update to make in the middle of a ballot. Thanks.

[edbratt]

Prior to merge, could I ask you to update the XML Binding 2.3 _index.md file to remove "Specification" from the title field meta-data? This breaks the sort order for the mid-level page and puts the v2.3 page at the bottom of the list.

[karianna]

LGTM

[lukasj]

Is there anything I need to do here to move this forward?