From 60e7eda437a16dd1c88833bb7613436fac1c0d3b Mon Sep 17 00:00:00 2001 From: Ivar Grimstad Date: Sun, 12 Nov 2023 09:09:11 +0100 Subject: [PATCH] Add minuts for Oct 31 and Nov 7 (#781) --- minutes/2023/2023-10-31.md | 64 +++++++++++++++++++++++ minutes/2023/2023.11.07.md | 104 +++++++++++++++++++++++++++++++++++++ minutes/minutes.md | 2 + 3 files changed, 170 insertions(+) create mode 100644 minutes/2023/2023-10-31.md create mode 100644 minutes/2023/2023.11.07.md diff --git a/minutes/2023/2023-10-31.md b/minutes/2023/2023-10-31.md new file mode 100644 index 0000000..0ca6eb3 --- /dev/null +++ b/minutes/2023/2023-10-31.md @@ -0,0 +1,64 @@ +# Jakarta EE Platform Call + +Date: 2023-10-31 + +Present (please put your name down here to mark yourself as present…): + +* Ed Burns (MSFT) +* Jared Anderson (IBM) +* Emily Jiang (IBM) +* Jim Krueger (IBM) +* Nathan Rauh (IBM) +* Ivar Grimstad (Eclipse Foundation) +* Dmitry Kornilov (Oracle) +* César Hernández +* Petr Aubrecht (Payara) + +## Agenda and Minutes + +### Housekeeping +* Arjan to run the meeting Nov 7, 14, 21, and 28 + +### [Jea-10](https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/10) ee-11-m1 +* Created GitHub milestone to track those that have already been published to maven central + * [https://github.com/jakartaee/platform/milestone/2](https://github.com/jakartaee/platform/milestone/2) +* Annotations done. + * Thanks. +* Data update + * M1 API and TCK in maven + * Nathan enumerated the steps he has been taking to minimize late-breaking objections from stakeholders with different opinions of design. + * Shared positive stories of engagement from these diverse stakeholders. +* Others that have a maven artifact + * cdi, cdi-el, lang-model have Alpha1 for API and up to Alpha5 for TCK + * interceptor has RC1 + * persistence has B01 + +### [Jea-69](https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/69) cdi centric [platform-552](https://github.com/jakartaee/platform/issues/552). +* Status? + +### [Jea-43](https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/43) Pruning managed beans +* Status? + +### [Jea-215](https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/215) API to expose platform versions [platform-762](https://github.com/jakartaee/platform/issues/762) +* I’d like to get clarity on whether or not we attempt this in EE 11. My gut instinct right now is: ~~no~~. maybe. +* The group discussed several aspects. + * The “override” case (if the vendor does not like the defaults) + * Platform defines the **WebProfile** interface, as in this [proposal](https://github.com/jakartaee/platform/issues/762#issuecomment-1741802201). + * This interface has a “lineup” of all the versions of all the specs in that platform. + * What about if an impl of a component spec wants to override? + * Do we need to consider this corner case? + * If so, isn’t this a kind of “config”, and if so, shouldn’t we be looking at this as Jakarta Config? + * What about the good old fashioned “Service Loader” technique? + * CDI and JSON specs currently use this. + * Dmitry gave an update on Config: Not available for use in EE11. +* Ed polled the group on the utility of the idea in general. + * Arjan and Nathan shared concrete examples for doing this. +* We would need to add TCK + * Platform TCK + * Web Profile TCK + * Core Profile TCK + +### Spec lead election for Jakarta Validation should happen asap. +* Scott Stark had already agreed to do this. + * Ed to check with Scott and confirm that he still accepts this heavy mantle. +* One of the existing committers just has to propose Scott Stark. \ No newline at end of file diff --git a/minutes/2023/2023.11.07.md b/minutes/2023/2023.11.07.md new file mode 100644 index 0000000..f898423 --- /dev/null +++ b/minutes/2023/2023.11.07.md @@ -0,0 +1,104 @@ +# Jakarta EE Platform Call + +Date: 2023-11-07 + +Present (please put your name down here to mark yourself as present…): + +* Scott Stark (Red Hat) Absent, unable to attend today +* Ed Burns (MSFT) +* John Clingan (Red Hat) +* Ivar Grimstad (Eclipse Foundation) +* Jared Anderson (IBM) +* Emily Jiang (IBM) +* Jim Krueger (IBM) +* Nathan Rauh (IBM) +* Thomas Watson (IBM) +* Adam Yoho (IBM) +* Jan Westerkamp (iJUG) +* Arjan Tijms (OmniFish) +* Kenji Kazumura (Fujitsu) +* Petr Aubrecht (Payara) +* David Matejcek (OmniFish) +* Brian Stansberry (Red Hat) +* Scott Marlow (Red Hat) +* Majid Mostafavi +* Cesar Hernandez (Tomitribe) + +## Agenda and Minutes + +### jakartaee-api default branch renamed from master to main +* An example of the new self-service: [https://github.com/jakartaee/.eclipsefdn/pull/1](https://github.com/jakartaee/.eclipsefdn/pull/1) +* Is there a technical benefit? + * Whatever the original reasons, it’s the new default now for GitHub + * MicroProfile + * Everything renamed by Emilly + * No problems observed + +### Housekeeping +* Arjan to run the meeting Nov 7, 14, 21, and 28 + +### [Jea-69](https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/69) cdi centric [platform-552](https://github.com/jakartaee/platform/issues/552). +* Status? +* Jakarta Persistence injection of EntityManager + * See [https://www.eclipse.org/lists/jpa-dev/msg00191.html](https://www.eclipse.org/lists/jpa-dev/msg00191.html) + * See [https://github.com/jakartaee/persistence/pull/460](https://github.com/jakartaee/persistence/pull/460) + * Where to put the tests if the spec is simply *supporting* CDI (as opposed to being based on CDI)? + * In the CDI EE integration spec? + * Alternative (and preferred future?): The integration tests could be placed in an optional TCK module for component specs not already depend on CDI + * Jakarta Persistence merely supports CDI (does not depend on it) + * EntityListeners are injectable by CDI + * Spring uses Jakarta Persistence, and persistence being dependent on CDI would be hard for them and/or break things. Same for Tomcat/Jetty. + * Do (some) Jakarta EE spec teams want to be SE only (and have EE somewhere else)? + * Some came from the JDK. They are not all EE focussed. + * Have tests that are only needed for EE certifications separate. +* Servlets becoming CDI beans + * [https://www.eclipse.org/lists/servlet-dev/msg00611.html](https://www.eclipse.org/lists/servlet-dev/msg00611.html) + * Should Servlets be injected in other places? (probably no) + * Do Servlets support interceptors? + * Give them the ability to have a scope, intercept them, decorate them, veto etc + * [https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#annotations-and-injection](https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#annotations-and-injection) + * + +### Some projects have few or no committers or leads missing + +### Status of CDI restructuring +* CDI Restructuring PR: [https://github.com/jakartaee/specifications/pull/665](https://github.com/jakartaee/specifications/pull/665) + * Ivar will contact Scott -> if done, kick of ballot +* CDI EE Creation PR: [https://github.com/jakartaee/specifications/pull/666](https://github.com/jakartaee/specifications/pull/666) + +### [Jea-10](https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/10) ee-11-m1 +* Created GitHub milestone to track those that have already been published to maven central + * [https://github.com/jakartaee/platform/milestone/2](https://github.com/jakartaee/platform/milestone/2) +* Others that have a maven artifact [jea-234](https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/234). + * cdi, cdi-el, lang-model have Alpha1 for API and up to Alpha5 for TCK + * interceptor has RC1 + * persistence has B01 + * —> (Re)publish M1 +* Other that DO NOT have a maven artifact yet + * Security specs + * Faces + +### [Jea-215](https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/215) API to expose platform versions [platform-762](https://github.com/jakartaee/platform/issues/762) +* I’d like to get clarity on whether or not we attempt this in EE 11. My gut instinct right now is: ~~no~~. maybe. +* The group discussed several aspects. + * The “override” case (if the vendor does not like the defaults) + * Platform defines the **WebProfile** interface, as in this [proposal](https://github.com/jakartaee/platform/issues/762#issuecomment-1741802201). + * This interface has a “lineup” of all the versions of all the specs in that platform. + * What about if an impl of a component spec wants to override? + * Do we need to consider this corner case? + * If so, isn’t this a kind of “config”, and if so, shouldn’t we be looking at this as Jakarta Config? + * What about the good old fashioned “Service Loader” technique? + * CDI and JSON specs currently use this. + * Dmitry gave an update on Config: Not available for use in EE11. +* Ed polled the group on the utility of the idea in general. + * Arjan and Nathan shared concrete examples for doing this. +* We would need to add TCK + * Platform TCK + * Web Profile TCK + * Core Profile TCK + +### Spec lead election for Jakarta Validation should happen asap. +* Election started + +### Social sharing: +* Was really nice to see recent LinkedIn conversation about helping with EE 11 TCKs refactoring [https://twitter.com/scottmarlow/status/1721540513671577730](https://twitter.com/scottmarlow/status/1721540513671577730) diff --git a/minutes/minutes.md b/minutes/minutes.md index 9964f36..c7d4981 100644 --- a/minutes/minutes.md +++ b/minutes/minutes.md @@ -8,6 +8,8 @@ ## [2023](#2023) +* [2023-11-07](2023/2023-11-07.md) +* [2023-10-31](2023/2023-10-31.md) * [2023-10-24](2023/2023-10-24.md) * [2023-10-17](2023/2023-10-17.md) * [2023-10-10](2023/2023-10-10.md)