-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] Drop Dagger DI? #294
Comments
https://quarkus.io/blog/on-the-road-to-cdi-compatibility/ https://dev.to/nutrymaco/using-arc-outside-quarkus-3pep It looks like it might be feasible to use Quarkus ArC 3.2+ (Cryostat 3.0 will also release using Quarkus 3.2.x) as a CDI-Lite DI system to replace Dagger, with just a little bit of extra work to enable the annotation processing. |
After a little more reading in depth there, this would entail creating a Maven plugin to do the annotation processing and bootstrapping the ArC process of generating classes. I'm not sure it's worth the burden of creating and maintaining that plugin when we already have the Dagger setup working well enough. If an official ArC plugin becomes available in the future it would be worth switching to. In the meantime, I think we should either stick with the Dagger status quo, or else consider switching to Avaje-inject. The build process for Avaje looks simpler than for Dagger, however it is a much smaller project that is less proven and has fewer eyeballs on it. |
Another benefit to dropping Dagger in favour of ArC (or any other CDI implementation) is that SmallRye Config has a CDI extension, which would allow us to largely remove the |
Another option other than ArC: https://activej.io/inject |
Currently we use Dagger for dependency injection in the Agent and in the main Cryostat 2.x line. Other Cryostat components - cryostat-reports and jfr-datasource - are Quarkus-based and therefore use Quarkus ArC.
Since Cryostat 3 is also Quarkus-based, the Agent will be our only consumer of Dagger. This has some downstream maintenance burden, so we should consider alternatives that have less maintenance burden.
The text was updated successfully, but these errors were encountered: