tracker for completion of Platform 9.0.0 TCK

[scottmarlow]

1. Complete the javax => jakarta class namespace changes [done]
2. Complete the javax => jakarta file name changes [ 100% done ]
3. Remove EJB interoperability [done ]
4. Remove Jakarta XML Registries [done ]
5. Remove Jakarta XML RPC [ done]
6. Remove Jakarta Deployment [ done ]
7. Remove Jakarta Management [ done ]
   7.1. Resolve errors in jakartaee-tck build [ done ]
8. Update signature tests for JDK 8 [ done ]
9. Defer Update TCK tests for JDK 11, also work with JDK 8](Update TCK tests for JDK 11 #213) [defer to after 9.0.0 release]
10. Update Jenkins CI jobs to release nightly build of 9.0.0 platform TCK (produce 9.0.0-SNAPSHOT or 9.0.0-b## artifacts) [done]
    10.1. Ensure that standalone TCK version numbers have been incremented [ done ]
11. Update scripts to use final released Jakarta EE 9 SPEC API jars [done]
12. After GlassFish 6.0 passes all standalone/Platform TCKs, run TCK release jobs [ ]
13. Update TCK README.md + wiki [ ]
14. Run/pass TCK release CI jobs for Platform 9.0.0 TCK and all standalone TCKs [ ]
15. Update lib/schemas references (e.g. install, release, tests under src) to use either EE 9 or Jakarta EE 8 schemas (as per Jan 21, 2020 VOTE: backward compatibility for descriptor schemas) [ done ]
16. Update configuration settings for GlassFish 6.0 configuration [ done]

[scottmarlow]

@bhatpmk @bshannon @jansupol what other EE 9 Platform TCK tasks do we need to add to this tracker issue? Thanks! :)

[bshannon]

Hopefully #10 would produce 9.0.0-SNAPSHOT or 9.0.0-b## artifacts.

I don't understand #11. The current platform API jar file job pulls the artifacts from Maven, not from GlassFish.

Depending on the magnitude of changes, the TCK Users Guide will probably also need to be updated.

Don't forget that everything needs to be "duplicated" for full platform and web profile.

[scottmarlow]

I don't understand #11. The current platform API jar file job pulls the artifacts from Maven, not from GlassFish.

Currently, as per comment in docker/build_jakartaeetck.sh#L98, we are temporarily pulling the artifacts from Maven, until we have GlassFish v6 with new api jars.

I like the idea of downloading API jars from Maven, instead of copying them from GlassFish. Apparently, we didn't do that before.

[bshannon]

I think we should keep pulling them from Maven. I'll see if I can find out the history of why
we didn't always do that.

[scottmarlow]

Should we block the Platform TCK 9.0.0 release on #15 being done? I think yes, as per Platform mailing list vote on Jan 21 results that were in favor of:

3. Support for Jakarta EE 8 *but not* earlier schemas is *required* in
   Jakarta EE 9 products; support for schemas earlier than Jakarta EE 8
   is *optional* in Jakarta EE 9 products.

[edbratt]

Perhaps after (2) this project should start producing snapshot stand-alone TCKs for the API and Implementation teams to use in their work.

[edbratt]

Consider if this effort should change the stage names. In CI properties and in test output, these use legacy names (i.e. jaspic, jacc, etc.).

[scottmarlow]

Quoting from @edbratt (thanks Ed, hope you don't mind me pasting this punch or checklist here):
Each TCK:

• is ported to org.jakarta name-space
• is available in it's stage location (tests, signatures, excludes, any other test config/setup material)
• is run against a compatible implementation, results available
• has been verified, reviewed,  and approved by the TCK Dev and API Spec. teams documentation (User Guide, etc.) has been updated and reader assigned reader (from previous item) has approved docs (reader checklist?)
• API Team has approved TCK (and all it's content) for ballot
• is released and signed by the Specification Committee