Look for atomicfu-gradle-plugin version in the buildscript of the current project as well.

[mvicsokolova]

We only looked for atomicfu-gradle-plugin version in the buildscript of the rootProject, though atomicfu may be applied for one module only, in this case we failed to resolve it's version.

An example of the project: integration-testing/examples/multi-module-test.

Fixes #403

[fzhinkin]

Should we take a version from project settings when building the plugin or something like that? The amount of places where we have to manually update the version string before a release continue growing and one day someone will definitely forget to change it.

[whyoleg]

Should we take a version from project settings when building the plugin or something like that?

If you are gonna to decide to do this, then all this hacks to fetch an atomicfu version from a build script will be not needed at all, as you will already know a version of the plugin :)

And IMO, this could be a better approach, than introducing this good error message, because in that case, there will be no need for it as there will be no need to add atomicfu to build classpath in user projects, and so just applying plugin will be enough :)
It will also resolve issues like #210, #137 or any other issues when users just apply plugin in some way (f.e via version catalogs) and not via buildscript.classpath (which is, AFAIK, is Gradle legacy and is not suggested approach)

There are multiple ways to do it, from manual ones to some existing Gradle plugins like this (which works pretty fine at my side)

[mvicsokolova]

Thank you! That's actually a much better approach.

[whyoleg]

sorry, the comment should be left here: #405 (comment)

[whyoleg]

My bad, looks like this could not work in all cases.
From last comment in a thread:

However, it fails for a multi-module gradle project where the plugin is added in the root projects as apply false, then applied without a version in the subproject.

Sorry, that I've sent a link to the specific message instead of just a thread :)

I was more thinking of the approach with a .properties file with version in it (mentioned in second comment) if we don't want to bring external plugin for such simple thing (which is fine).

Also, I've found more recent thread (Sep 2023) where there is even better suggestion without a need for a file generation, as it's the safest and conventional way.

And BTW KGP does the same!

• build setup is here, though most likely the task name here will be just processResources
• template project.properties file is here
• function to read version is here
• example of usage is here
• And additionally, just may be it will also help, here is the commit in KGP which adds additional property to this file, so it touches all affected places mentioned earlier (though, it's from 2019, so some code could be moved already)

[mvicsokolova]

Thank you for the great navigation 🔥!) Seems, that this approach worked for me.
I've pushed a commit with atomicfu.properties file generation.

[whyoleg]

Nice!