Did you see Antoine’s blog in March?:
Yes. With (truly!!) all respect to Antoine, it's a bit all over the place and not a list of use cases or goals.
Can we just put down here, in simple bullet point formats, what at least the goals of this effort are?
I don't mean to suggest this is a trivial exercise, because it is not, and Emily certainly tried to get it rolling before (mostly unsuccessfully) with issue #425 (
https://github.com/eclipse-ee4j/cdi/issues/425; and I applaud her attempt to start with the use cases). But let's try again, here, publicly, on this list.
For the record, I'm definitely aware of {handwave} build time {handwave} no reflection {handwave} but I'm quite sure we can do better than that as a group. Here is an incomplete sketch of one example of the sort of thing I had in mind.
Meta-goal: disrupt the specification as little as humanly possible (true of all specifications everywhere that are this old)
Goal: permit a CDI SeContainer to run a precomputed set of beans without having to run portable extensions
Why: certain products create their beans at build time/ahead of time: we want them to be part of the CDI fold as well
Hindrance: the SeContainerInitializer/portable extension APIs, even with something like SeContainerInitializer.disableDiscovery().addExtension(new Extension() { /* add beans here however they are generated/created */ }) is insufficient because of X, Y and Z
Hindrance: all (not just some) portable extensions must be available at runtime via BeanManager#getExtension()
…etc. and so on. I can see the germs of something like this lurking in your posts and others' and in Antoine's blog article and elsewhere but I think it is necessary that we have small, traceable, actionable goals spelled out here before we try to solve them.
Best,
Laird