Had an interesting dependency conflict recently. ...

# kotest

[Rob Elliot]

Had an interesting dependency conflict recently.

We have an implementation(platform("org.jetbrains.kotlin:kotlin-bom:6.1.1")) declaration.

We updated our dependency on net.javacrumbs.json-unit:json-unit-kotest from 5.1.0 to 5.1.1, which depends on io.kotest:kotest-assertions-core-jvm:6.1.5 and transitively on io.kotest:kotest-assertions-shared:6.1.5 -> io.kotest:kotest-assertions-shared-jvm:6.1.5.

When we run it blows up as so:

java.lang.NoClassDefFoundError: io/kotest/matchers/jvmerrorcollector
	at io.kotest.engine.test.interceptors.CoroutineErrorCollectorInterceptor.intercept(CoroutineErrorCollectorInterceptor.kt:38)
	at io.kotest.engine.test.TestCaseExecutor$execute$3$1.invoke(TestCaseExecutor.kt:120)
	at io.kotest.engine.test.interceptors.CoroutineDispatcherFactoryTestInterceptor.intercept(CoroutineDispatcherFactoryTestInterceptor.kt:41)
	at io.kotest.engine.test.TestCaseExecutor$execute$3$1.invoke(TestCaseExecutor.kt:120)
	at io.kotest.engine.test.interceptors.SupervisorScopeInterceptor$intercept$2.invokeSuspend(SupervisorScopeInterceptor.kt:23)

I think because jvmerrorcollector has moved from io.kotest.matchers to io.kotest.assertions between io.kotest:kotest-assertions-shared-jvm 6.1.1 and 6.1.5.

CoroutineErrorCollectorInterceptor is in io.kotest:kotest-framework-engine-jvm.

So:
io.kotest:kotest-framework-engine-jvm:6.1.1 depends on io.kotest:kotest-assertions-shared-jvm:6.1.1
net.javacrumbs.json-unit:json-unit-kotest:5.1.1 depends on io.kotest:kotest-assertions-shared-jvm:6.1.5

Which are incompatible because io.kotest:kotest-assertions-shared-jvm:6.1.5 is not backwards compatible with io.kotest:kotest-assertions-shared-jvm:6.1.1.

I think removing io.kotest.matchers.jvmerrorcollector from io.kotest:kotest-assertions-shared-jvm should have required a major version bump, which would in turn have alerted net.javacrumbs.json-unit:json-unit-kotest that it needed a major version bump, which would have made it more obvious to me that there was an incompatibility between my kotest 6 dependency and its transitive kotest 7 dependency.

[Oliver.O]

That was a mistake, completely unintentional.

[Rob Elliot]

Got you. Have you experimented with automated checking for this sort of thing that would make it impossible to break binary compatibility without bumping major versions? It's something I've always wanted to do and never got round to...

[Oliver.O]

I wasn't involved in these changes (because testballoon), but generally, Kotest has ABI checks in place. However, it's still a manual process of checking the ABI differences before routinely running gradlew updateKotlinAbi.

[sam]

Yeah was my messup. Once the break was realized we figured it was best to revert it and minimize the damage rather than leave the change in for the rest of all future 6.x releases

[sam]

Not my best moment

[Rob Elliot]

np, easy to do, that's why I'm keen to try and add an automated check to prevent it to my stuff