Artifact coordinates changed in 5.x releases for Maven users

[Robert Važan]

Could you provide guidance on how to deal with okhttp-jvm/okhttp JAR mixup? Given app A and library L, both upgrade paths are perilous:

App first: A -> L + okhttp-jvm:5, L -> okhttp:4
Library first: A -> L + okhttp:4, L -> okhttp-jvm:5

Both cases get resolved by maven to A -> okhttp:4 + okhttp-jvm:5, which will result in class loading conflicts at runtime.

From library point of view, no matter which version of okhttp is chosen, some dependent apps will end up with broken build. It looks like the only solution is to bundle okhttp under library's package tree. Or am I missing something?

[Jesse Wilson]

Yeah sorry about this. We're using gradle everywhere which papers over this problem. Will look into building a better story for Maven users.

[Yuri Schimke]

Is this the fix? https://kotlinlang.slack.com/archives/C3PQML5NU/p1655635540306199

publishing {
    publications {
        val jvm = getByName<MavenPublication>("jvm")
        getByName<MavenPublication>("kotlinMultiplatform") {
            pom.withXml {
                val root = asNode()
                val dependencies = ((root["dependencies"] as NodeList).firstOrNull() as Node?)?.apply {
                    for (child in children().toList()) remove(child as Node)
                } ?: root.appendNode("dependencies")
                dependencies.appendNode("dependency").apply {
                    appendNode("groupId", jvm.groupId)
                    appendNode("artifactId", jvm.artifactId)
                    appendNode("version", jvm.version)
                    appendNode("scope", "compile")
                }
            }
        }
    }
}

[Jake Wharton]

That would depend on what the type and contents of the binary for the multiplatform artifact was. Seems like a better option would be to change the suffixes to have the JVM artifact the unqualified one with the Gradle module metadata.

[Jesse Wilson]

I’m gonna try doing this on both OkHttp and Okio
#7354
square/okio#1125