Allow extensions to inject a MavenArtifactResolver
#39955
Conversation
quarkus-bot
bot
added
area/core
area/devtools
|
I'd like to know @aloubyansky's opinion on this. @Sanne was also curious about it. |
|
@dmlloyd I'd like to avoid this as much as possible. I remember you bringing this up some time ago but I forgot the details. Could you describe what qbicc needs specifically? |
| @@ -23,6 +23,7 @@ | |||
| import io.quarkus.maven.dependency.ResolvedDependency; | |||
| import io.quarkus.paths.PathCollection; | |||
| import io.quarkus.paths.PathList; | |||
| import io.smallrye.common.constraint.Assert; | |||
In order to build a native image, qbicc needs its own JDK/runtime JARs to link against. So from the extension, I need a way to ensure that qbicc finds its runtime JARs. When qbicc runs standalone, it uses a standalone Maven resolver to get those JARs. But this resolver doesn't really work inside of Quarkus because of JAR version differences and potentially missing Maven APIs, etc. The qbicc runtime JARs cannot be on the application's normal class path without causing major malfunction, so adding them as normal dependencies (either to the application by some magic API, or to the |
|
About a dozen JARs totaling maybe 20MB or so? Not giant I guess, but pretty large. |
In order for the qbicc extension to work, qbicc needs to be able to download additional Maven dependencies (specifically, the qbicc JDK JARs). We want to use the same Maven resolver which Quarkus is using so we do not end up with disparate configurations which could manifest in weird ways.
This PR allows extensions to inject the
MavenArtifactResolver. The code to handle the injection has a one-off check for that specific type. We could expand this to support general injection, but before we do that we might consider actually having a general DI container of some sort for extensions instead. Opened as a draft to foster some discussion.