gradle
Depending on relocated artifact pointing to artifact with capability leads to conflict
Current Behavior
The org.lz4:lz4-java:1.8.1 artifact contains a relocation pom that points to the new at.yawk.lz4:lz4-java:1.8.1 location. That artifact defines a capability for org.lz4.
Depending on org.lz4:lz4-java:1.8.1 in gradle produces the following error:
% ./gradlew run
> Task :compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
> Could not resolve org.lz4:lz4-java:1.8.1.
Required by:
root project :
> Module 'org.lz4:lz4-java' has been rejected:
Cannot select module with conflict on capability 'org.lz4:lz4-java:1.8.1' also provided by [at.yawk.lz4:lz4-java:1.8.1(apiElements)]
> Could not resolve at.yawk.lz4:lz4-java:1.8.1.
Required by:
root project : > org.lz4:lz4-java:1.8.1
> Module 'at.yawk.lz4:lz4-java' has been rejected:
Cannot select module with conflict on capability 'org.lz4:lz4-java:1.8.1' also provided by [org.lz4:lz4-java:1.8.1(compile)]
The workaround is to depend on the new group ID, but this is not possible if org.lz4 comes from a transitive dependency. In that case, a capabilities resolution is necessary.
Expected Behavior
The dependency should cleanly relocate to at.yawk.lz4:lz4-java:1.8.1 without error.
Context (optional)
See issue description and workaround here: https://github.com/yawkat/lz4-java/wiki/Gradle-and-org.lz4:lz4%E2%80%90java:1.8.1
Self-contained Reproducer Project
https://github.com/yawkat/test-case-gradle-rename-capability
./gradlew run
Gradle version
8.14
Build scan URL (optional)
No response
Your Environment (optional)
No response
Unfortunately for us I think this is a duplicate of a fairly old issue: https://github.com/gradle/gradle/issues/1256
I'd really like it to be resolved though...
Definitely related, if that issue wouldn't exist, this issue wouldn't either probably. But this issue is more serious, because now with the recommended setup, you get a build error. That issue is just a "this feels strange, please change it". And if the new artifact does not have GMM or does not follow the recommendation to have the old capability too, then the old issue is still the same.
But here you have the recommended setup and get an unnecessary build failure.
When resolving it with the mentioned work-around, you actually also work-around that old issue.
But this capability conflict resolution should be done built-in by default. So:
- capability conflict
- one candidate is relocated to the other candidate
- no further candidates exist => resolve the conflict automatically in favor of the relocation target
That would also resolve that old issue for libraries that properly publish the capabilities, it would then only be present for libraries that do not and there it could then be considered acceptable.
Or actually, it might even be beneficious to auto-add the capability of the old relocated artifact to the relocation target, at least if no explicit GMM is published just like variants are derived if no explicit GMM is present. This would then completely solve that old issue along, except if the relocation target publishes GMM but does not contain the old capability, but that could then be considered a publishing bug.
