Skip to content

Commit

Permalink
Add minuts for Oct 31 and Nov 7 (jakartaee#781)
Browse files Browse the repository at this point in the history
  • Loading branch information
ivargrimstad authored Nov 12, 2023
1 parent a98126a commit 60e7eda
Show file tree
Hide file tree
Showing 3 changed files with 170 additions and 0 deletions.
64 changes: 64 additions & 0 deletions minutes/2023/2023-10-31.md
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.
104 changes: 104 additions & 0 deletions minutes/2023/2023.11.07.md
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)
2 changes: 2 additions & 0 deletions minutes/minutes.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down

0 comments on commit 60e7eda

Please sign in to comment.