[cdi-dev] Back on the topic of beans.xml and bean archive handling for L

[Matej Novotny <manovotn@xxxxxxxxxx>]

Hello,

bean archive and beans.xml in Lite is one of the topics we haven't reached an agreement on, so I thought I'd open the discussion again.
Below is my take on what I wanted to capture with it and why I think it would work. While I read CDI spec I of course I might have missed something so as usual, I am open to feedback.

Looking at beans.xml for Lite first; I wanted to define it in a way that:
 * Lite bean archive will use a subset of what is in Full (e.g. you can transfer such archive to Full and it will behave equally regarding whether it is a bean archive and regarding discovery)
 * Will still define Lite discovery as annotated because that is a natural fit
 * Will allow defining that an archive discovery should be skipped

With these in mind, I think we could define Lite in the specification with following restrictions:
 1) Lite requires beans.xml to be present
 2) Lite requires this file to contain discovery mode and eligible modes are `annotated` and `none`
   - any other mode would (probably?) result in an error
 3) Any other content of beans.xml is NOT parsed
   - no need to error on non-empty beans.xml IMO
 4) Archives without beans.xml or with empty beans.xml result in non-portable behaviour

The above should be a subset of Full behaviour while at the same time achieving what we need in Lite.
FTR, this will (unfortunately) still break existing Quarkus behaviour but it IMO in a manageable way where a config option can fix it.


Moving on to the second topic since they go hand in hand - in Lite we were talking about having a singular bean archive.
Now, why I say these topics go hand in hand is because the following lines presume the beans.xml behaviour I described above!
I think that if we avoid specifically saying whether Lite is or isn't a singular archive, we would achieve just that and be compatible with how Full behaves.
Remember that in Lite there are no EE visibility restrictions in play and there are no per-archive enablements (alternatives, interceptors, ...) as we do not allow/parse them from beans.xml.
Whether this is implemented as singular archive or multiple archives is then an impl detail that doesn't make a difference because it will behave as singular archive anyway.
WDYT, does it make sense?

BTW I plan to breach both of these topics on the call later today so if you will be present, you can hit me up there.

Regards
Matej