In Gradle, properly handle relocated artifacts in conditional dependency resolution

[reaver585]

Summary
In Gradle, conditional dependency resolution currently fails when encountering relocation artifacts (e.g. io.quarkus:quarkus-resteasy-reactive-qute:3.15.1 -> io.quarkus:quarkus-rest-qute), due to setTransitive(false) being applied in the new resolver. This has surfaced in #49714, #49700.

Details

• In the new Gradle component-variant–based resolver, conditional dependencies are resolved with setTransitive(false).
• The relocation target artifact is not resolved, leading to failures (XXX did not resolve to any artifacts).

Expected Behavior
Relocation artifacts should be properly resolved to their target coordinates, and dependency matching should be done against the relocated GAV.

[quarkus-bot]

/cc @glefloch, @quarkusio/devtools

[reaver585]

@aloubyansky first and obvious question: can't we just setTransitive(true)?

[aloubyansky]

We may have to. What we need to identify the final artifact though.

We could consider a couple of approaches.

1. We keep the current code as the default approach. If it didn't resolve any artifacts then it's probably a relocation. Perhaps, only in this case we could re-resolve with setTransitive(true) and look for the first (and only?) direct dependency, which is probably the target artifact? To be verified.

2. We do always use setTransitive(true) and analyze the dependency graph to figure out the target artifact (whether it's relocated or not).

[aloubyansky]

The reason I setTransitive(false) was to avoid resolving transitive dependencies in case they are not needed. This is a conditional dependency evaluation. In many cases the condition for this dependency will not be satisfied and so we won't need to resolve its transitive dependencies.

[reaver585]

Got it. I have a PR that implements the first approach, we might need to polish it - I'm yet to add logic to check that it's a direct dependency. It wouldn't help if there is a relocation of a relocation though.. But that's a bridge too far, perhaps? And we could just ignore such a use case..

[aloubyansky]

Just in case, you could do that with configuration.getResolvedConfiguration().getFirstLevelModuleDependencies()

[aloubyansky]

It wouldn't help if there is a relocation of a relocation though.. But that's a bridge too far, perhaps? And we could just ignore such a use case..

We could start with that.