This has been discussed, one of the issues is the difference between the way Quarkus and Micronaut works.
It is actually possible to do this in Micronaut because Micronaut computes additional classes that represent the beans and places alongside the byte code of the classes that represent your extension.
This means you could ship these beans and potentially load them as CDI runtime extensions. In fact this is what Helidon has done with their Micronaut integration.
Quarkus works differently by post processing byte code and JAR files in their "raw" form and adding enhancements only to the application archive (Red Hat people correct me if I am wrong).
I had asked this question early on and I will admit I am far from
a CDI implementation expert. Is it possible to position the build
time extension API in a way that it can replace the current
runtime extension API down the line? Can there be a future version
of the runtime extension API that can simply build on the proposed
build time extension API?
Longer term, this could mean the current runtime extension API
could be pruned and replaced. This would make CDI
Lite/Static/Native actually a longer term proper subset of CDI
full.
Has this already been considered?
Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual
community member and do not reflect the views of my employer.
On 1/27/21 11:13 AM, Manfred Riem
wrote:
+1 on answering this question
From: cdi-dev
<cdi-dev-bounces@xxxxxxxxxxx>On Behalf Of
Thiago Henrique Hupner Sent: Wednesday, January 27, 2021 8:47 AM To: cdi developer discussions
<cdi-dev@xxxxxxxxxxx> Subject: Re: [cdi-dev] CDI profiles (was RE: About
parsing beans.xml files in Lite)
The build time extensions wouldn't be
able to run in runtime if needed?