Now, I fully understand the need and support CDI in general going in this direction. I just think something needs to be done a bit better and maybe it's just the name (so picking a name that does not tend to imply a subset but rather a variant).
True. Just for the sake of discussion, this was my initial thought on how things would fit together. Maybe it's not correct, but it's just something to shoot at:
Hopefully we can get it clear what all the layers of a CDI stack exactly represent if it’s going to be a subset indeed. E.g.:
Jakarta DI - small set of annotations, previously shared with Guice, HK2, Spring, etc now privately used by Jakarta CDI.
Jakarta CDI Build-time (Lite?) - Beans, qualifiers, scopes, stereotypes, buildtime portable extensions
Jakarta CDI Core - Alternatives, Decorators, runtime portable extensions
Jakarta CDI EE - Rules for EJB beans and servlet components, bean names and scope in _expression_ language, specifically including Faces and Pages, build-in beans for Jakarta Transaction, Jakarta Security, Jakarta Servlet
There's many variants possible. As Jakarta DI is not shared with Spring and Guice etc, we could opt to move it. Maybe include it in CDI Lite, or, go the other direction, move some of the things from the proposed CDI Lite into Jakarta DI.
Additionally, over time Jakarta CDI EE may get smaller as some things like the build-in beans could be moved to their respective specifications.
Kind regards,
Arjan
