Breaking up spec/TCK to remove circular dependencies

[starksm64]

A long standing issue is that we references to downstream specifications like Servlet, Transactions, etc. A summary of the issues can be found in the following Jakarta EE 11 issue:

https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/98

The most correct thing is to break up the specification and TCKs into separate repos that layer the dependencies. This is something that is being done for MP-JWT to allow separation on the Jakarta dependencies.

The simplest thing todo is simply separate the TCK into finer grain artifacts that also layer the dependencies.

The only problem with this is that ideally a TCK that describes requirements for CDI/Servlet integration would be released as part of the Serlvet specification ballot.

Tasks for EE 11

• Extract Integration requirement to a section of the specification into a platform/profile specification
• Move web TCK test module to the platform spec
• Remove the web test module from the CDI TCK core

[Ladicek]

I would like to point out one thing: in CDI, the spec and the TCK are already broken apart. The CDI spec depends only on projects that are "below" CDI (Jakarta Annotations, Jakarta Interceptors, Jakarta Dependency Injection, Jakarta Expression Language).

Further, the CDI TCK is also broken apart: there are some supplementary modules, the CDI Lang Model TCK (which is not interesting here), and 2 main TCK modules:

• impl, which contains tests for Core CDI and CDI SE and only depends on projects that are "below" CDI,
• web, which contains tests for CDI EE and depends also on projects that are "above" CDI.

So technically, we could release CDI early and CDI TCK late. That probably breaks some rules, so another option, probably a path of least resistance, is to break out the web module into something like cdi-tck-ee. Then, CDI and CDI TCK would be released early, and CDI TCK EE would be released late. Would something like that work?

I generally agree that if CDI is truly a corner stone of Jakarta EE, then it should be the projects "above" CDI who specify how they integrate with CDI, but historically, there hasn't been a lot of enthusiasm for doing that.

[edburns]

Names TBD

Scott's proposal

1. Take the current CDI spec and break it up into

   • "CDI integration spec" this is where behaviors relative to other
     Jakarta EE specs, downstream dependencies, are specified. It is
     an integration spec because it is a spec that covers the
     integration between CDI and everything else.

   • "CDI implementation spec" the rest of the spec after the
     integrations have been taken out.

2. TCK

   • CDI integration spec will have its own TCK.

   • CDI implementation spec will have its own TCK.

   • There will be no shared tests between these two TCKs.

3. Jakarta EE Core profile will only reference "CDI implementation spec".

4. Jakarta EE Web and Platform will reference "CDI integration spec" and
   "CDI implementation spec".

5. What about the POMs for the TCKs?

   Consider these.

   • web/pom.xml

     We plan to pull the web/pom.xml out of the CDI TCK distribution
     and put it into a new artifact associated with the "CDI integration
     spec".

   • impl/pom.xml

   • lang-model/pom.xml

     These will be in the TCK for "CDI implementation spec".

6. What about the waves?

   "CDI integration spec" will be in wave 7

   "CDI implementation spec" will be in wave 3

[starksm64]

So technically, we could release CDI early and CDI TCK late. That probably breaks some rules, so another option, probably a path of least resistance, is to break out the web module into something like cdi-tck-ee. Then, CDI and CDI TCK would be released early, and CDI TCK EE would be released late. Would something like that work?

Yes, this breaks the current IP flow of the Jakarta specification process where the voting happens on the spec and TCK. As you point out, it really should not take much work to simply break the CDI spec into a base and integration specs with attendant TCKs that would produce two clear spec/TCK bundles that follow the specification process rules.

[Ladicek]

I see. Given that I'm skeptical about other specs adopting the CDI integration concerns, I think moving the CDI EE spec out CDI itself into another specification called "CDI EE" would be easiest. On the TCK front, that basically amounts to moving the web module into a TCK of the new spec.

Why would I call it "CDI EE"? Because that's how it called today. The less changes, the better :-)

[starksm64]

It won't be outside of the CDI project, it will simply be another specification like dependency injection managed by the CDI specification project. A CDI EE + current web submodule of existing TCK would be the contents as you are saying.

[JanWesterkamp-iJUG]

I agree, in the future the integration tests of the CDI integration spec should move to the component spec TCKs, as they are located above the CDI (implementation spec) in the dependency tree.
Unfortunately there is a lack of resources to separate these TCKs from the (old) Jakarta Platform TCK at the moment and nobody wants to integrate the CDI (web) tests there too...

So extracting them into a separate spec is a useful workaround for this circular dependency. Renaming it makes sense too, as the current CDI TCK Web Impl contains dependencies to Jakarta Platform specs beyond the Jakarta Web Profile.

Alternatively splitting it up into two separate CDI integation specs might be possible, but creates more work, while offers the option for Web Profile only implementations to run their part as required tests and (full) Platform implementation also need to pass the additional required tests. Problems with this Web Profile integration might be detected earlier then and Web Profile only implementations have their set of required tests too.

Defining new umbrella spec TCKs and move the tests there is another option, but then they need to be run additionally to the existing Jakarta Platform TCK. But this complicates certification of umbrella spec implementations - but it could help the transition of the TCKs and would allow adding tests for new features there when the TCK is not extracted yet for that component spec. As a side effect, there is no new wave created, as it can be tested as part of the Jakarta Platform release.

A low level option could be to release the current CDI and fix the CDI TCK Web Impl when all it's dependencies released finally. This would fix the deviating dependencies in a 2nd TCK Patch/Service Release but would not solve the issue to esnure the tests are run as required tests with the final dependencies at the specific Jakarta Platform/Profile.

A mixed approach is possible too, i.e. separate the Web Profile dependent tests into a separate spec with it's own TCK and extract the TCKs for the Platform level dependencies to add the tests there. The beauty of this is sharing the work between component spec teams, but there are no current plans to do this TCK extraction for Jakarta Connectors (Jakarta Resources in Maven) or Jakarta Messaging (Jakarta JMS in Maven). As a fallback in case of lack of resources there, a 2nd separate CDI (Platform) integration spec with a TCK or a new Platform TCK spec containing these tests could be created then.

Unfortunately there is no nice and simple solution to solve this issue completely - I think extrating these two integration specs in CDI, creating new Platform TCKs or move them to the extracted TCKs of other component specs are the options - the difference is only the responsible team: CDI, Platform [TCK] or other component spec teams (like Jakarta Messeging, Jakata Connectors, etc.). Solving this issue inside the CDI project has the benefit of being able to act independently (except the fact that Platform need to add the new specs in the according waves).

[edburns]

Hello @starksm64 and @Ladicek. Based on this comment:

Why would I call it "CDI EE"? Because that's how it called today. The less changes, the better :-)

Can you please confirm:

• What I called "CDI integration spec" will be called "Jakarta Contexts and Dependency Injection Enterprise Edition (Jakarta CDI EE)".
• What I called "CDI implementation spec" will be called "Jakarta Contexts and Dependency Injection Enterprise Edition (Jakarta CDI)".

[JanWesterkamp-iJUG]

I highlighted the Platform level component spec integration tests in the current CDI TCK Web Impl above and list them here again for clarification:

• Jakarta Messaging
• Jakarta Connectors

[JanWesterkamp-iJUG]

@starksm64: Luckily, the fact that the Jakarta Messaging need to be released on wave 6 and Jakarta Connectors in wave 4 latest, it will be sufficent to have one single Jakarta CDI Integration spec in wave 7 containing two separate TCK artifacts, one adressing the Jakarta Web Profile component specs integration only and a 2nd one that contains the Jakarta Platform component spec integration additionally to the first one.

So Jakarta Web Profile only implementations have their TCK test collection and Jakarta Platform ones have an additional one (that includes the first one) to certify.

I will update the CN4J report accordingly.

[Emily-Jiang]

Another solution is to move the CDI EE part to either web profile or platform spec and then put the tcks in the respective repo and CDI team owns the tests. In this way, there won't be individual -ee specs, which might double the spec sizes for no apparent content addition. It will be nicer to have the umbrella spec contains the spec interactions.

[hantsy]

A little confused about the CDI EE, why not move the CDI and spec integration to the certain spec.

• For example, Original CDI Servlet support in CDI 4.0, move it to Servlet, add a CDI support section in Servlet spec. If possible provide a new module under servlet for CDI- jakarta.servlet.cdi.

  Faces, Jaxrs can split the Injection Provider SPI and implementation, and provide default implementation by CDI, in Jakarta EE environment, the injection is enabled by CDI, in Spring etc,(no CDI implementation in the classpath), it can be provided by Spring.

  For those specs integrated CDI tightly, CDI is part of the deps.

• Thus we only have a CDI spec which can run on Java SE or Jakarta EE Container, and can be a direct dep for other specs(or its CDI module).

[Ladicek]

Feel free to ask the Servlet spec if they want to own the CDI integration concerns :-)

Hint: they already indicated in the past that they don't, see e.g. jakartaee/servlet#116 or https://issues.redhat.com/browse/CDI-492

[starksm64]

@arjan tijms ***@***.***> is going to ask on the servlet dev list. The issue in the past has been that the servlet core team was not interested in CDI integration, and so this really is an EE platform integration issue that should be done in a separate spec to avoid dependency issues. For now this is happening in CDI EE. In the future it could be a Web Profile integration spec.

…

On Wed, Oct 25, 2023 at 1:38 AM Ladislav Thon ***@***.***> wrote: Feel free to ask the Servlet spec if they want to own the CDI integration concerns :-) Hint: they already indicated in the past that they don't, see e.g. jakartaee/servlet#116 <jakartaee/servlet#116> or https://issues.redhat.com/browse/CDI-492 — Reply to this email directly, view it on GitHub <#687 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRDMTL2GNWU742RKYLHM3YBC6XZAVCNFSM6AAAAAA2QFMNNGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZYGY4DQOJTGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[starksm64]

So the restructuring review ballot to move the integration contents into a new CDI EE spec failed the spec committee ballot due to question about whether this was a general approach all specs should take. What has been decided as the approach for EE 11 is to have integration requirements move into the corresponding platform spec or profile. A new restructuring review ballot for this change will kick off this week.

[hantsy]

@Ladicek Another possible to make the Servlet CDI integration like functionality as a standalone module under CDI parent. Thus we can avoid circular deps.

[Ladicek]

I would frankly prefer CDI EE over putting things into the platform spec, because of clear ownership. But I won't lose sleep over it :-)

[edburns]

I have incorporated the latest on this matter into the EE 11 release plan. I seek your review at jakartaee/platform#808 @Ladicek @starksm64 .

[Emily-Jiang]

@starksm64 what's the progress on this?

[starksm64]

The bulk of the work on the CDI component spec project side is done with:
#755
jakartaee/cdi-tck#532

There will still be work needed to complete the integration of the CDI EE requirements into the platform as part of this PR:
jakartaee/platform#838