Hi team, I have a <Kotlin JVM project> that depend...

# announcements

[Philipp Hanslovsky]

Hi team,
I have a Kotlin JVM project that depends on org.jetbrains.kotlin:kotlin-compiler-embeddable:jar:1.4.30:compile, which introduces the JetBrains trove4j fork org.jetbrains.intellij.deps:trove4j:jar:1.0.20181211:runtime as a transitive dependency. (entire dependency tree in thread). One of the usage scenarios installs the jars and transitive dependencies into a program that already has GNU trove4j as a dependency, but in an incompatible version. What is the best way to avoid dependency clashes here? I tried shading all of kotlin-compiler-embeddable and the jetbrains trove4j into the jar that I generate for installation and it works. Is this the recommended way to solve this clash between jetbrains trove4j fork and GNUE trove4j? If anyone has examples, I would like to take a look at those to make sure, I only include the dependencies necessary and also don't leave out anything.

[Philipp Hanslovsky]

Dependency tree:

--- maven-dependency-plugin:3.1.2:tree (default-cli) @ scripting-kotlin ---
org.scijava:scripting-kotlin:jar:0.1.2-SNAPSHOT
+- org.scijava:scijava-common:jar:2.83.3:compile
|  +- org.scijava:parsington:jar:2.0.0:compile
|  \- org.bushe:eventbus:jar:1.4:compile
+- org.jetbrains.kotlin:kotlin-compiler-embeddable:jar:1.4.30:compile
|  +- org.jetbrains.kotlin:kotlin-script-runtime:jar:1.4.30:runtime
|  +- org.jetbrains.kotlin:kotlin-reflect:jar:1.4.30:runtime
|  +- org.jetbrains.kotlin:kotlin-daemon-embeddable:jar:1.4.30:runtime
|  \- org.jetbrains.intellij.deps:trove4j:jar:1.0.20181211:runtime
+- org.jetbrains.kotlin:kotlin-stdlib:jar:1.4.30:compile
|  +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.4.30:compile
|  \- org.jetbrains:annotations:jar:13.0:compile
+- org.jetbrains.kotlin:kotlin-scripting-jsr223:jar:1.4.30:compile
|  +- org.jetbrains.kotlin:kotlin-scripting-common:jar:1.4.30:runtime
|  |  \- org.jetbrains.kotlinx:kotlinx-coroutines-core:jar:1.3.8:runtime
|  +- org.jetbrains.kotlin:kotlin-scripting-jvm:jar:1.4.30:runtime
|  +- org.jetbrains.kotlin:kotlin-scripting-jvm-host:jar:1.4.30:runtime
|  \- org.jetbrains.kotlin:kotlin-scripting-compiler-embeddable:jar:1.4.30:runtime
|     \- org.jetbrains.kotlin:kotlin-scripting-compiler-impl-embeddable:jar:1.4.30:runtime
+- junit:junit:jar:4.13:test
|  \- org.hamcrest:hamcrest-core:jar:1.3:test
+- org.scijava:scijava-common:jar:tests:2.83.3:test
\- org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.4.30:compile
   \- org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.4.30:compile

[James Richardson]

I think all the solutions are probably quite hard work. You say installing into a program... maybe you can use a classloader to separate out the different versions? Repackaging/vendoring the clashing classes is also a possibility, maybe that's shading.

[Philipp Hanslovsky]

Yes, that's what shading does and, thankfully, the maven shade plugin makes that fairly easy. The actual program itself is not in my control (I am shipping a plugin), so I don't have access to the classloader, unfortunately.