forked from jakartaee/platform
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add minuts for Oct 31 and Nov 7 (jakartaee#781)
- Loading branch information
1 parent
a98126a
commit 60e7eda
Showing
3 changed files
with
170 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters