What are the currently maintained artifacts? Are some about to be phased out?

[LouisCAD]

Hi, I'm asking this because I want to make an updated object reference like this for the community to easily discover the artifacts offered by KoTest, and ensure they can share the version definition.

I'm concerned because I see some artifacts are on different versions here:

• 4.0.5
• 4.0.6
• 4.0.7
• 4.1.0
• 4.1.1
• 4.0.0-BETA1
• 4.0.3

… and I plan to have a rule to get all artifacts on the same version, which here, would break badly if you use the latest, at least for some dependencies.

So, please, can you give some info about what are the currently maintained artifacts that are available in latest release, and some visibility on the ones that you see going away in the not so distant future?

Ideally, you can even follow the style of the legacy KotlinTest artifacts definition I linked above, and submit a small PR on this file in the develop branch, allowing edits for maintainers so I can complete additional tasks like version sync rule and tests.

Thanks for your help. This is all about helping the Kotlin and Gradle communities keep up with dependencies updates and avoid tech debt accumulation that could happen more easily otherwise, especially in projects defining dependency constants in buildSrc, or projects with many modules and versions to sync.

[LouisCAD]

Also, related to #1569

[sksamuel]

Ok, so the main dependencies a user should care about are:

kotest-properties(-jvm,js) for property testing kotest-assertions-core(-jvm,js,native) for the basic assertions library kotest-runner-junit5-jvm for the testing framework support.

Each can be used independently.

These won't change in the near future, and since the kotlintest->kotest rename haven't changed and won't change.

Then there are a bunch of extension libraries, things like:

kotest-assertions-arrow-jvm

and

kotest-extensions-allure-jvm

These are very specific and usually obvious from their name what they do.

Versions are bumped together. So when we release 4.2.0 all these deps will go to 4.2.0 together.

Now, happy to create a PR. Are you looking for a kotest object in here that has the deps I talked about? If so I can create. Can you give me context on what it's used for?

[LouisCAD]

You can get more context in this usage guide, the 6 screenshots should help to quickly get the hang of it.

Note that the plugin requires Gradle 6+, where Gradle Metadata is enabled by default, so since you're multiplatform compatible, it should be safe to just the provide the main artifacts without "polluting" with the platform specific suffixed ones.

Here's the link where you can start the PR: https://github.com/jmfayard/refreshVersions/blob/develop/plugins/dependencies/src/main/kotlin/dependencies/Testing.kt#L58

No worries if you forget anything or make a little typo, I'll run tests locally to ensure the dependencies are alright.

BTW, thanks for your quick response! I'm happy I'll be able to move quicker than I expected on this (I mean just before my vacations really begin 😅 ).

[sksamuel]

Ok I see. I will raise a PR.

[sksamuel]

PR raised.

https://github.com/jmfayard/refreshVersions/pull/206

[LouisCAD]

Am I right that you used to publish kotest on jcenter, but are now releasing to mavenCentral and that jcenter is out of sync?

[sksamuel]

I've never published on jcenter. They must do some kind of sync.

On Sun, 19 Jul 2020 at 15:19, Louis CAD notifications@github.com wrote:

Am I right that you used to publish kotest on jcenter, but are now releasing to mavenCentral and that jcenter is out of sync?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kotest/kotest/issues/1570#issuecomment-660702573, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFVSGTUL22FJ22YHEK6OBTR4NIORANCNFSM4O7NPYOA .

[LouisCAD]

Oh, so their sync is broken in a way then. I reached out to bintray support. I'm closing this issue since the problem is not your end but on jcenter/bintray's end. Thanks for helping pinpoint this.

[LouisCAD]

Ok, I learned from bintray support that jcenter is a "lazy" mirror of MavenCentral, so it's not the place to look for updates of a dependency published on MavenCentral only, but once you know the version, you can get it from jcenter, which will fetch and persist it on first request.

[sksamuel]

Ok makes sense. Is there any reason to not just get it from maven central ?

[LouisCAD]

I don't see any, but I know some projects might have jcenter() setup, without having mavenCentral() defined. Might make sense to warn for these cases in refreshVersions (shouldn't affect other cases unless they also need to lookup dependency versions in the repo).

[sksamuel]

Makes sense. :+1: