hello, sorry to bother again, how would you handle...
# kotest
t
hello, sorry to bother again, how would you handle Intellij importing the wrong dependency? I try to be concise, but this might get long. I created a sample project to show the issue: https://github.com/ThanksForAllTheFish/classgraph here it goes (and please, let me know if I get anything wrong): • kotest framework engine 4.2 relies on classpagraph 4.8.89, but declares the dependency as
implementation
therefore gradle does not add the dependency to the compile classpath, due the java library plugin: https://github.com/kotest/kotest/blob/master/kotest-framework/kotest-framework-discovery/build.gradle.kts • springdoc ui is maven project, so not that sophisticated, and relies on webjars, which in turns relies on classgraph 4.8.69: https://github.com/webjars/webjars-locator-core/blob/master/pom.xml#L57 • in between those 2 releases of classgraph, a new method
rejectPackages
was added and is used by kotest, for instance https://github.com/kotest/kotest/blob/master/kotest-framework/kotest-framework-engine/src/jvmMain/kotlin/io/kotest/engine/config/detectConfig.kt#L28 • because in kotest the dependency is at runtime only, idea does not see and when running a test from the ide it fails due to a method not found exception and crashes the testframework it was quite hard to debug, the failure can be seen with a breakpoint https://github.com/kotest/kotest/blob/master/kotest-framework/kotest-framework-engine/src/jvmMain/kotlin/io/kotest/engine/launcher/execute.kt#L84 but it is not logged anywhere I could find see pictures, no dep for kotest, 4.8.69 for springdoc in the first one, the error in the second
I solved it for now adding
testImplementation("io.github.classgraph:classgraph:4.8.89")
directly to my gradle file and it is not strictly a kotest issue, I think, unless kotest plugin is somehow involved
l
I don't think the plugin is involved. It seems that gradle shenanigans got to you
An alternative would be to exclude the old dependency from SpringDoc UI
It's probably defined somewhere as a compile scope of some sort
s
I'll change it to compile, I don't trust that gradle implementation thing
l
It might be maven the one that's stealing the dependency
s
@thanksforallthefish what is the output you see in intellij when this fails? Does it give you a stack trace at least ?
t
declaring the dependency at
api
in kotest should do the trick, but it feels hackish. it means kotest would leak the dependency and applications would have it at available at (test) runtime. otoh webjars is a maven project and I don't think maven has the same sophistication. you can define runtime and compile dependencies, but it is not the same meaning as in a gradle library
intellj gives me nothing, no output excepts that the engine framework crashed. no reason. I feel I got lucky in finding the issue in just a couple of hours, it could very well have taken a couple of years 😂
s
So the launcher code is supposed to report exceptions back to the test listener, so it should show up in the console
that's a bigger bug than the classpath thing I think
t
that for sure a bigger problem. the classpath issue I think it is actually a problem with the ide, probably the gradle plugin for intellij, since cli gradle works just fine. I will open an issue to jetbrains for the dependency resolution and see what they say
s
I've fixed the engine not reporting these errors and just saying Test framework quit
t
you are really really fast
s
This was caused by not handling Throwables in our startCoroutine code
So this wouldn't fix the classpath thing (seperate change for that) but it would at least have given you the error immediately
4.2.3 will be released shortly
t
my jetbrains ticket is not found 🤔
s
They don't like you 😉
t
eh eh, they don’t hate me. it is only visible to logged id users, I must have done something weird while creating it as guest
s
ah
4.2.3 is out