Runtime errors due to dependency version conflicts

[gabrielfeo]

Currently, either the Kotlin Jupyter kernel does not perform any version conflict resolution when there are multiple versions of a dependency or it's picking a lower version. This can lead to hard-to-diagnose runtime failures.

Example cases

• This commit in the repository of a real Kotlin Jupyter library fails with a NoClassDefFoundError for a class that neither the notebook nor the library use directly: gabrielfeo/develocity-api-kotlin@d3fe344 (build scan). The cause is that the okhttp library, being upgraded to a new version in that commit, started requiring okio:3.15.0 and its new classes at runtime (on it's pom file). As other dependencies also require okio at different versions, including okio:3.7.0, the Kotlin kernel prioritizes okio:3.7.0 in the classpath and there's a runtime failure. By default, in a Gradle project, it would be transparent to the user that 3.15.0 be chosen for runtime, based on version conflict resolution.
• The gabrielfeo/kotlin-jupyter-version-conflict-repro repository is a minimal reproducer of a slightly different case, which is changing the order of two dependencies in the pom, both of which depend on okio for runtime (one on 3.7.0, the other on 3.15.0). This also results in the NoClassDefFoundError error.

Proposed solution

My proposal is that kotlin-jupyter perform dependency version conflict resolution always picking the highest version of each requested artifact. That's the most compatible strategy. I believe this issue might hit more users as Kotlin notebooks adoption increases, and that resolving it would result in a better experience for the end-user by aligning default behavior with Gradle, which is the de facto standard for Kotlin developers. Ideally, when %trackClasspath (or a new option) is on, conflict resolution would be logged for troubleshooting.