As we are creating a Kotest Bom, what about a Kotest version catalog? It's an incubating gradle feat...

# kotest

[LeoColman]

As we are creating a Kotest Bom, what about a Kotest version catalog? It's an incubating gradle feature, but seems solid

[Javier]

it is not incubating since 7.4 :)

[thanksforallthefish]

there was some analysis at https://github.com/spring-projects/spring-boot/issues/29588 on limitations of version catalog.

definitely a topic I am not familiar with, but Wilkinson seemed really sure of their assertions 🤷

[LeoColman]

Their main point was about supporting bom, and I think gradle catalog supports importing bom now

[LeoColman]

https://docs.gradle.org/current/userguide/platforms.html#sub:bom_import

[thanksforallthefish]

from that discussion I got that platform (which supports importing boms) and catalog are different things though, and from what I read catalog does not support transitive dependencies right?

[thanksforallthefish]

A catalog helps with centralizing the dependency versions and is only, as it name implies, a catalog of dependencies you can pick from.

vs

A platform is a more heavyweight construct: it’s a component of a dependency graph, like any other library. If you depend on a platform, that platform is itself a component in the graph

[sam]

We don't really need to support a bom in our own list of dependencies as we are at the bottom of the food chain.

[sam]

It's different for spring which sits higher and relies on loads of deps

[sam]

I think we should look to do this

[Emil Kantis]

Cool idea 🙂 Started trying it out a bit but ran into an issue.. Trying to get some help resolving it atm. https://github.com/kotest/kotest/pull/3171