You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a proposal on how Build Compatible Extensions ( e.g. CDI Lite extensions) could look like. Various discussions in the past showed that regardless of what would CDI Lite look like, it will need some form of extensions because the existing ones are not suitable for build-time and extension are an important factor for integration of various frameworks.
This issue and the PR linked to it (#451) come with a WIP proposition that we would like to gather feedback on.
There is a blog post on CDI website that you should check out. It goes deeper into what Build Compatible Extensions Proposal is and how it works. Please do give it a read.
What it isn't
This proposal does not aim to cover what CDI Lite should/shouldn't contain and focuses solely on how could the Lite extension API look like.
How can I play with this new API
The linked PR gives you a glimpse of what the API draft looks like right now. However, that's just API - it's nice but you cannot try it out in action, right?
That's why we have also created a simple implementation for the annotation transformation part of API inside Quarkus. It uses none of Quarkus-specific APIs, just what we presented here and having tried that in Quarkus proves its viability for build-time environments (although it doesn't limit it for just that). For the sake of simplicity it right now contains a copy of the APIs inside the fork.
Got an idea how to improve it? What's missing or what's superfluous? We'd love to hear what you think of this API!
In order to keep it all in a readable and traceable format, please provide your feedback in form of separate GH issue on this repo with label lite-extension-api.
The text was updated successfully, but these errors were encountered:
TL;DR
Blog post you should read - www.cdi-spec.org/news/2020/09/15/CDI_Lite_extension/
PR with API proposal - #451
For hands-on playing with API, use this fork - https://github.com/Ladicek/quarkus-fork/tree/experiment-cdi-lite-ext
What is this
This is a proposal on how Build Compatible Extensions ( e.g. CDI Lite extensions) could look like. Various discussions in the past showed that regardless of what would CDI Lite look like, it will need some form of extensions because the existing ones are not suitable for build-time and extension are an important factor for integration of various frameworks.
This issue and the PR linked to it (#451) come with a WIP proposition that we would like to gather feedback on.
There is a blog post on CDI website that you should check out. It goes deeper into what Build Compatible Extensions Proposal is and how it works. Please do give it a read.
What it isn't
This proposal does not aim to cover what CDI Lite should/shouldn't contain and focuses solely on how could the Lite extension API look like.
How can I play with this new API
The linked PR gives you a glimpse of what the API draft looks like right now. However, that's just API - it's nice but you cannot try it out in action, right?
That's why we have also created a simple implementation for the annotation transformation part of API inside Quarkus. It uses none of Quarkus-specific APIs, just what we presented here and having tried that in Quarkus proves its viability for build-time environments (although it doesn't limit it for just that). For the sake of simplicity it right now contains a copy of the APIs inside the fork.
Intructions on how to try it out are in the blog post.
How to provide feedback
Got an idea how to improve it? What's missing or what's superfluous? We'd love to hear what you think of this API!
In order to keep it all in a readable and traceable format, please provide your feedback in form of separate GH issue on this repo with label
lite-extension-api
.The text was updated successfully, but these errors were encountered: