https://kotlinlang.org logo
Join Slack
Powered by
<@U019YR8UJ8L> I'm scared of releasing the junit u...
# kotest-contributors
e
@mitch I'm scared of releasing the junit update 😅 have you tried it out locally?
Mostly because I don't know wtf it might affect. Sam said something about IntelliJ, which is why I'm asking.. I guess we don't have tests which spin up the IDE and check that reporting is working as intended
m
Let me look at it again. I only briefly tried it on gradle. Yeah I’m on the same boat now seeing Sam’s comment 😱
ok confirmed gradle jvm with complex filters works, let me try intellij
s
It should be fine I just know in the past it caused some issue
We should use the lowest version we can get away with using
m
right… by the way intellij works as well
yeah i used 5.8.2. that seems to be fine. 5.9.1 has even more breaking change
e
Is it only an issue when mixing JUnit + Kotest? https://github.com/kotest/kotest/issues/3261 And if he has a direct dependency on a newer JUnit version, wouldn't that override the version Kotest pulls in anyway?
m
yeah that’s right but i guess the problem there is there’s a reflection somewhere that wanted a class only present in 5.8.x
that happened because kotest was compiled against 5.7.x
@Emil Kantis should we proceed with merging?
e
I guess it's unlikely to cause problems.. I still don't see why this problem happens though 😞
Is this the dependency tree we expect to cause problems?
The class mentioned (ClassOrderer) was introduced in JUnit 5.8, and should exist if the user runs with 5.9 (But perhaps moved?)
It's never used in Kotest, but I guess it might be reflectively used if present?
Kotest's Junit 5.7 dependence should not be the issue I think, if the user pulls in 5.9 themselves that should take precedence over any transitive dependency
I'll throw up a project which pulls in JUnit 5.9 and mixes it with the Kotest snapshot build before we release.. Snapshot build is hopefully done soon
The solution might also be to downgrade mockk to a version that is on JUnit 5.7?
m
@Emil Kantis if you try using gradle filters you might hit a different code path in junit
e
I'll try a gradle filter, sec..
Nope.. That's also good:
Copy code
~/workspace/kotest-junit-issue-repro main +2 !1 ?1 > ./gradlew test --tests "my.pack.*"                                                                                                                                                                                                                                                                                    23:09:50

BUILD SUCCESSFUL in 4s
4 actionable tasks: 4 executed
m
actually that may be the same. If we take a look at that exception that was reported by the two users, that can only happen if junit 5.7.x is in the wrong order in the classpath
Copy code
Caused by: org.junit.platform.commons.JUnitException: TestEngine with ID 'junit-jupiter' failed to discover tests
	at org.junit.platform.launcher.core.EngineDiscoveryOrchestrator.discoverEngineRoot(EngineDiscoveryOrchestrator.java:111)
	at org.junit.platform.launcher.core.EngineDiscoveryOrchestrator.discover(EngineDiscoveryOrchestrator.java:85)
	at org.junit.platform.launcher.core.DefaultLauncher.discover(DefaultLauncher.java:92)
	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
	at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
	... 16 more
Caused by: java.lang.NoClassDefFoundError: org/junit/jupiter/api/ClassOrderer
	at org.junit.jupiter.engine.config.DefaultJupiterConfiguration.<clinit>(DefaultJupiterConfiguration.java:50)
	at org.junit.jupiter.engine.JupiterTestEngine.discover(JupiterTestEngine.java:66)
	at org.junit.platform.launcher.core.EngineDiscoveryOrchestrator.discoverEngineRoot(EngineDiscoveryOrchestrator.java:103)
	... 23 more
you’d need to somehow have both 5.8.x and 5.7.x in the classpath, and make sure that 5.7.x is found first
e
Not really sure how classloading works.. What determines the order? And how would you manage to make maven/gradle put both on the classpath?
m
hmm good question, I have seen that before with both maven and gradle. There needs to be some setup that was compiled to run against 5.8, but then you force that to 5.7 perhaps i’ll try reordering the libraries.
you can also force the dependency to use 5.7 and this will happen
runtime* dependency
e
I tried something like this and still no failure..
Copy code
dependencies {
    testImplementation("io.kotest:kotest-runner-junit5:5.5.1") {
        exclude(group = "org.junit.jupiter")
    }
    testImplementation("org.junit.jupiter:junit-jupiter-api:5.7.2")
    testImplementation("org.junit.jupiter:junit-jupiter-engine:5.7.2")
}
If you feel we should just go with 5.5.3 @ JUnit 5.8.2 then we can do that of course.. I just have a hard time seeing what the problem is.. 🙂
m
@Emil Kantis something like this
I know that’s probably a different error but yeah. that happens. sometimes it does pull both versions
@Emil Kantis this reproduces it
Copy code
dependencies {
    testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:5.8.2")
    testImplementation(libs.kotest.property)
    testImplementation(libs.kotest.runner.junit5)
    testImplementation("org.junit.jupiter:junit-jupiter-api") {
        version {
            strictly("5.7.1")
        }
    }
}
e
okay.. now try adding 
includeBuild("<path to kotest@master>")
in 
settings.gradle.kts
and see if it changes anything
m
ah well i’ve forced that api to 5.7.1 there explicitly so anything we’d do won’t work as engine is reflecting on 5.8.2 and will explode at api 5.7.1
i can’t get gradle to trick classpath ordering yet, but conceptually that will happen if we have both classes in the runtime classpath in the unfortunate order.
e
I dont even get how both end up being on the classpath 🤯
Even if Kotest is built with 5.7, 5.9 should be added onto the classpath by Gradle if there's' someone else pulling it in..
Copy code
org.junit.jupiter:junit-jupiter-api:5.7.2 -> 5.9.1 (*)
m
Something like this can happen. If something like this exists, then gradle will just yolo append it iirc lol
Copy code
test.runtimeClasspath = newJunitRuntimeClasspath + kotestRuntimeClasspath + projectTestClasspath
e
At least that's how I thought it works
lol.. 😂 if someone does that they kinda sorta deserve what's coming to them
m
indeed there’s no helping there
e
Maybe that's kinda what happens when someone adds kotest as a dependency for. the maven-surefire plugin
m
perhaps. i’m not too surprised there. Maven classpath ordering is literally based on what order you put the xml dependency at.
The latest kotest aligning to 5.8.2 will cover our bases at least that will not pull 5.7.x to the classpath even if our users decided to do the cursed classpath append trick
e
Given that we'll eventually have to upgrade Junit version anyway, perhaps it's as good time as any to try to get this out and hope it solves people's problems?
🤷
m
yeah i agree. having kotest dep pull both 5.7.x and 5.8.x transitively (due to mockk) is not good..
better to align it. we’ve also verified it works with 5.8.x
and you’ve even tried with 5.9.1 !
e
I think there's a definite risk of someone doing it the other way around now 😂
Kotest pulling JUnit 5.8 and somehow they put 5.7 onto the classpath some other way
but I guess we were adding both as it was..?
m
lol! the other way around is easily pushed back by saying, yep bruh update your junit
expectation management 😂
e
true.. might be good to add some info about it in the release notes tho
m
yeah that’s right. I’d put kotest junit 5 runtime now requires junit 5.8.2.
e
Copy code
Update JUnit version from 5.7.2 to 5.8.2

Note: If your build somehow manages to put both JUnit 5.7 _and_ 5.8 onto the classpath and they load in the wrong order, you might see problems related to `ClassOrderer` not being found. Please make sure that _only_ JUnit 5.8+ is loaded
m
that’s awesome!
e
Copy code
Update JUnit version from 5.7.2 to 5.8.2

Kotest now _requires_ the runtime version of JUnit to be _at least_ 5.8

Note: If your build somehow manages to put both JUnit 5.7 _and_ 5.8 onto the classpath and they load in the wrong order, you might see problems related to `ClassOrderer` not being found. Please make sure that _only_ JUnit 5.8+ is loaded
?
or is that too much lol
m
it’s accurate. there is a breaking change in 5.8.2 where they added a few stuff and how the reflections were done.
e
do you have access to sonatype?
m
idk maybe not 😆
e
you'd recognise it if you did 😂 feels like being back on internet of the early 2000s
m
haha that’s right, these kinds of UI was a huge style improvement back then lol
oh I don’t have an account
how do I even register lol there’s no create account button 🤕
or is that an admin ui for someone in sonatype?
e
It's connected to their JIRA 😁
m
ohh
e
I think you can get an account here: https://issues.sonatype.org/
and then you need to raise an issue and ask to be added to the io.kotest group, and sam will need to approve it.. but then you'll be able to log onto the fancy interface 🤓
m
haha cool let me try that
e
Another possibility would be to use something like https://github.com/vanniktech/gradle-maven-publish-plugin to automate the maven-central steps as well
Maven central integration. The plugin makes it easy to configure publishing to Maven Central with dedicated APIs to set it up and configure everything that is required. It also avoids issues like having multiple staging repositories on Sonatype OSS and supports automatic releasing without requiring any interaction with the web interface.
Okay, releasing is rolling out to central now. Thanks for taking the time to dig into the issue with me 🙂 Bed time here, so I'll be heading off 🌔
m
thanks man!! really appreciate it
Im still trying to register to sonatype lol
s
You need me to approve it. Ill be back stateside Nov 4th and I'll contact sonatype then so you have full permissions mitchell
m
Thanks Sam!
87 Views
Open in Slack
PreviousNext
Powered by