New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Artifact coordinates changed in 5.x releases for Maven users #7339
Comments
Yeah sorry about this. We're using gradle everywhere which papers over this problem. Will look into building a better story for Maven users. |
Is this the fix? https://kotlinlang.slack.com/archives/C3PQML5NU/p1655635540306199
|
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. |
I’m gonna try doing this on both OkHttp and Okio |
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?
The text was updated successfully, but these errors were encountered: