Dependencies with conflicting name:version jar filenames

A rare corner appears with Google’s cloud-trace-java library. Given two (poorly named) dependencies:

com.google.cloud.trace.v1:sink:0.3.2
com.google.cloud.trace:sink:0.3.2

one will be lost when packaging sink-0.3.2.jar into a WAR. Using this project in Eclipse gives the error:

Invalid classpath .../sink-0.3.2.jar. The project contains another dependency with the same archive name.

There’s a discussion where the proposed solution is having the maintainers rename one library to sink-api. That seems reasonable but can anything be done right now by the Gradle user? Is there something like Jar.archiveName or ArtifactHandler that applies to Eclipse / WAR generation or the initial JAR download?

This is a bit hacky, but you can rename the jar as it goes into the war file:

war {
    duplicatesStrategy = DuplicatesStrategy.FAIL
    rootSpec.eachFile { fcd ->
        if (fcd.sourcePath =~ /sink/) {
            // Path looks like GRADLE_USER_HOME caches/com.google.cloud.trace/sink/0.3.2/346ef8b68e7ef86ae2db3b942b8f1f4e6c487a19/sink-0.3.2.jar
            def groupName = fcd.file.parentFile.parentFile.parentFile.parentFile.name
            fcd.name = groupName + "-" + fcd.name
        }
    }
}

This makes the jars named com.google.cloud.trace.v1-sink-0.3.2.jar and com.google.cloud.trace-sink-0.3.2.jar respectively.

Thanks! I’ll give that a try.

Any thoughts on how to fix the Eclipse side? The Eclipse plugin generates .classpath entries pointing right into the Gradle cache so renaming seems like it’d have to happen at the source. Is that directory/file layout format of the dependency cache configurable?