Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Discussion: The new structure of EE integration sections

Exactly because of this I proposed that each spec that integrates with CDI should define the integration points itself. And also if it integrates with another spec.

Creating a new spec for every combination when specs integrate together can easily backfire and become unmanageable. We can do that when it's not clear which of spec should define the integration. But with CDI it's pretty clear - it's meant to be the core glue spec and everything should be built on top. So the other specs integrate to it.

Ondro

On Fri, Nov 17, 2023 at 6:20 PM Scott Stark via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
Largely we would favor 1 as it should be written to enable claims of valid behavior even in cases where there is a combination of specifications that do not constitute a profile. This is how users make use of today's modular application servers. As to the con, I would make it a single specification that only has new sections added, not separate specifications.

On Thu, Nov 16, 2023 at 9:19 AM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
Further to this week's discussion regarding where to put EE integration chapters for Jakarta Specifications, we need to discuss offline to evaluate the approaches. At the moment, CDI EE was proposed to be a new spec (see here) while Jakarta Persistence with CDI integration was proposed to be added to the platform specification (see here). It is better to be consistent across the platform project.

Context: some Jakarta EE specifications have integration parts with other Jakarta EE specifications, such as CDI or potentially Jakarta Persistence.

Issue: These dependencies might introduce some circular dependencies among the specs. In order to avoid the circular dependencies, the integration parts need to be somewhere else.

Proposals:
Proposal 1: Create a new specification to hold all of the integration part, such as CDI EE, Persistence EE
Pros:
The ownership is clear to start with but it might not be once the relevant specs start adding tcks.

Cons:
The number of specs might be increased dramatically.
For some certification with web/core profile or platform, separate parts are to be spelled to differentiate web/core profile or platform implementers.


Proposal 2: put the integration part to Core/Web Profile or Platform specifications under separate modules.
Pros:
The number of the specs will not change.
It is clear that certification for core/web profile and platform are clear which tcks are to be executed.
This can be released when releasing the platform or web profile or core profile. However, these TCKs can be released individually.

Cons:
The ownership is less clear. It might not be an issue if the involved spec teams work together on this or the tests clearly document the owners.


Please add other proposals and cons/pros I missed.
--
Thanks
Emily

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top