Am I right to conclude that `io.kotest.extensions:...

# kotest

[Benoît Liessens]

Am I right to conclude that io.kotest.extensions:kotest-extensions-clock:1.0.0 is obsolete as type TestClock is now part of io.kotest:kotest-extensions:6.0.0.M6 ?
The old clock extensions is still referenced in the 6.0.0 docs

[sam]

yes, can you link to the docs page, I will fix

[Benoît Liessens]

https://kotest.io/docs/next/extensions/test_clock.html

[sam]

thanks fixed docs

[sam]

M8 is out btw

[Benoît Liessens]

Was trying to upgrade to 6.0.0.M8 but some kotest deps cannot be resolved …
Is that just a matter of time for things (in Maven central) to get in sync?

[sam]

possibly, which deps ?

[sam]

maven central changed the way everything was published so it kinda threw a spanner in the works last minute

[Benoît Liessens]

> Could not find io.kotest:kotest-runner-junit5:6.0.0.M8.
     Searched in the following locations:

[sam]

https://central.sonatype.com/artifact/io.kotest/kotest-runner-junit5/versions

[sam]

its there

[Benoît Liessens]

note I’m resolving deps though a corporate artifact proxy

[sam]

that's prob delayed

[sam]

M8 was like 1hr ago

[Benoît Liessens]

Correct.
Things do work when adding mavenCentral() as repo.
Thanks

[sam]

great

[sam]

let me know if you find any showstoppers on M8

[sam]

this could be the last Mx before an RC

[sam]

docs have been updated btw https://kotest.io/docs/next/extensions/test_clock.html

[Benoît Liessens]

I did have to remove some -jvm suffixes from kotest dependencies. Not sure why that is nor what the recommend approach is to declare deps (with or without -jvm suffix) for plain JVM builds

[sam]

I think the Jetbrains recommendation is that you shouldn't need -jvm

[sam]

gradle is supposed to work that out for you

[Emil Kantis]

are you using maven?

[Benoît Liessens]

Hell no

[Emil Kantis]

Then you should never add -jvm 🙂 like sam says, gradle figures that out

[sam]

lol "hell no"

[Benoît Liessens]

So that (no -jvm suffix) holds true for my ktor and kotlinx-serialization deps too I suspect ?

[sam]

yep

[Benoît Liessens]

Excellent, live support from the community 😁

[sam]

the -jvm is a maven thing. Gradle has a concept of "attributes" where the build system can say I want this dep with an attribute of "jvm" and it figures it out

[Benoît Liessens]

thanks folks

[sam]

https://docs.gradle.org/current/userguide/variant_attributes.html

[sam]

the docs aren't super clear

[Benoît Liessens]

never really put my head to that Gradle Variant stuff … I now have a good reason to change that

[sam]

I hope the gradle folks never see this but gradle is the worst API I've worked with in 27 years of being a professional developer

[sam]

I feel like even the experts don't understand it

[Emil Kantis]

i don't think you have to.. it should just work. In my experience , it does..

[Benoît Liessens]

^ that

[Benoît Liessens]

but I agree it’s one of these ever-moving APIs …

[Emil Kantis]

lol 😄 yeah the api is maybe not great..

[sam]

basically they adopted a bunch of "magic" because they used groovy and have been paying the price since

[sam]

it's horrible

[sam]

what they're doing now with the Kotlin DSL is great, but they're kinda hamstrung

[Benoît Liessens]

history is bound to repeat itself …. wasn’t their (long time ago) a story about a revolutionary email client written in python. After much work they concluded refactoring is a mess in dynamically typed language. Not sure what happened to that project …