Date: 2020-02-18
Present:
- Kevin Sutter (IBM)
- Andy McCright (IBM)
- Paul Nicolucci (IBM)
- Ivar Grimstad (Eclipse Foundation)
- Scott Marlow (Red Hat)
- Nitin Dahyabhai (IBM, WTP PMC)
- Brian Stansberry (Red Hat)
- Steve Millidge (Payara)
- Kenji Kazumura (Fujitsu)
- Bill Shannon (Oracle)
- Emily Jiang (IBM)
- Scott Kurz (IBM)
- Nathan Erwin (Eclipse Contributor)
Agenda
Excellent progress on the Milestone/RC API jar files! [KWS]
https://github.com/orgs/eclipse-ee4j/projects/17#column-7346435
- Waves 0, 1, and 3 have completed their API updates
- Wave 2 is only missing Jakarta Mail
- Wave 4 is missing JTA, Batch, and JAX-RS
- Wave 5 is missing EJB, Enterprise WS, JSTL, and Connectors
- Wave 6 is missing Faces
- Wave 7 is missing Platform and Web Profile
Specifications, TCKs, and CIs are next [KWS]
- Any questions/issues - please post to Platform Dev Mailing List or ping Kevin directly
- Glassfish CI - hasn’t really kicked off, just preliminary planning
- Also dependent on the independent CIs (tyrus, jersey, mail, etc)
- Need planning from the Glassfish team (APIs and CIs integration)
- Kick off early next week (Steve) or Fujitsu could kick it off earlier
Criteria for replacing the TCKs. [BS]
- Discussed how to ensure that a “refactored” TCK is a sufficient replacement to the original (previous version)
- Is each individual Spec project responsible to verify the re-factoring? Is that sufficient? Or, do we need some external checks-and-balances?
- In the past (J2EE, Java EE), the TCKs were incrementally modified. Easier to monitor the changes going in.
- Structured reviews might help ensure consistency. Participants from Spec Project team, the Platform TCK team, the Spec Project TCK team are required.
- Common framework for the TCKs? Or, allow each independent TCK to determine the framework used? A common framework is probably key to the success of this effort.
- Defining a common framework would allow each Project to plug in their TCK and be executed as part of the overall Platform TCK.
- Requirement – allow the use of the existing TCK tests themselves. If all of the TCK tests need to be modified just to become part of this new infrastructure, the process will die. We need the ability to incorporate existing TCK tests. Maybe that’s through some build magic or wrappering of the tests or something…
- Excellent start to this discussion, but needs much more work. Who should drive this effort? Platform TCK? An individual TCK (ie. json-b or json-p)? Group effort? Post to the Platform TCK mailing list and ask for volunteers. (KWS)
