i have a gradle dependency that has been maven relocated to a new group id, and the new group id also provides the old group as a capability. depending on the old group id (and that group id only) gives the following error, even though only one dependency is declared:

% ./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)]

poc: https://github.com/yawkat/test-case-gradle-rename-capability is this a bug or is the metadata not supposed to be used this way?

Looks fine to me from a cursory look. Especially if the packages inside the artifact did not change. The documentation even encourages to use capabilities like this at https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:relocation_duplicate_dependencies. So I have a strong feeling that this indeed is a bug.

The docs encourages using capabilities to detect possible conflicts, which means error out with a conflict at resolution time, rather than possibly have two artifacts with duplicate (and possibly different) classes at compile-time or runtime. My understanding is that you still need to resolve the conflict. In this specific case, it should be enough to replace the dependency with the new coordinates. In other cases (you depend on the new coordinates, but you also have a transitive dependency on an older version at the old coordinates, before the relocation) you'll want to use a capability resolution rule to tell Gradle to use the new artifact, at the new coordinates. https://docs.gradle.org/current/userguide/component_capabilities.html#sec:selecting-between-candidates So to me it looks like the expected behavior. Could Gradle do better when the conflict arises specifically with the relocated artifact? Sure, but that's more a request for enhancement than a bug (you're expected to update the coordinates when you update the version, not to use the relocation)

i think it makes no sense to get a conflict when you declare a single dependency. a relocated dependency should behave like the new dependency, not like having the old and the new.

@Thomas Broyer there is no conflict

Depends what one thinks the purpose of the relocation is. My opinion: you should never directly use (depend on) it. It's there so people (browsing Central) and tools (think dependabot/renovatebot, or the various Gradle plugins assisting you in keeping your dependencies up-to-date) know / can discover there's a new version, but that new version lives at different coordinates, so when you update, you change both the version and the coordinates. IIRC, Maven warns when you depend on a relocation, telling you to update the coordinates.

hmm well even if i add dependency constraints to new versions of at.yawk.lz4, i guess it will still break since it'll pull in the 1.8.1 with the capabilities, which i cant fix anymore

That's why I said "instead of using the capabilities", and yes in your case it's too late (unless you publish another relocation for a newer version, where the relocated version uses dependency constraints; not sure I'd recommend doing that though)

i wonder what will happen if a gradle project depends on a maven project which in turn depends on org.lz4lz4 java1.8.1. i guess this issue could "poison" an entire dependency tree for gradle

So IMO: • depend on the new coordinates, never on the relocation • open a request for enhancement for Gradle to be smarter about relocations and conflicting capabilities (but I suspect there might be many edge cases), or possibly that they update their stance and instead recommend the dependency constraint path.

Why change the publishing? The publishing with the capabilities is fine and exactly what the Gradle documentation recommends.

i guess i better add a big fat warning to the release notes before people start depending on the relocation

It's not unusable, just not as convenient as it could be

could you be so kind as to make a simple snippet to resolve the conflict so i can document this? if i write it it probably won't be idiomatic. otherwise i'll ask @melix

selecting the highest version here does not work of course as both have the same version:

configurations.configureEach {
    resolutionStrategy {
        capabilitiesResolution {
            withCapability("org.lz4:lz4-java") {
                selectHighestVersion()
            }
        }
    }
}

That would be in the typical situation (old version in old coords and new version in new coords). But in that situation you can for example filter by group, this works, just tested:

configurations.configureEach {
    resolutionStrategy {
        capabilitiesResolution {
            withCapability("org.lz4:lz4-java") {
                select(candidates.first { (it.id as ModuleComponentIdentifier).group == "at.yawk.lz4" })
            }
        }
    }
}

https://github.com/yawkat/lz4-java/wiki/Gradle-and-org.lz4:lz4%E2%80%90java:1.8.1 https://github.com/gradle/gradle/issues/35916