This message was deleted.

Short answer: you can't know. Long answer: there may be many tasks which require the version to be set, not just jar. For example, you may have a task which reads the version to generate a properties file. Or you can have a task which reads the version to generate a source file (so before

compileJava

). Or, you can have plugins which reason on the version to configure things differently (e.g if SNAPSHOT is used, etc...). It is unfortunate that there's no

Provider<String>

for

version

and

group

yet, which would be a better fit for your use case, but in general, you simply cannot know.

So basically you are suggesting we set the version right after project evaluation?

This is far too late. Do it as early as possible.

Note that

project.version

is an

Object

, so you can actually make it compute (and memoize) its

toString()

dynamically. Not saying you should do it that way, but it works (or at least, it worked!) https://github.com/tbroyer/gradle-incap-helper/blob/21afe339d6281ee040db5547cbded7ff21b59ae8/build-logic/src/main/kotlin/VersionFromGit.kt https://github.com/tbroyer/gradle-incap-helper/blob/21afe339d6281ee040db5547cbded7ff21b59ae8/build.gradle.kts

Yeah, poor man's

Provider

😄

I am currently using tasks and the caching mechanism to calculate the version So what i have is a executeVersionCalculation -> writes and stores cached file, readVersion (reads the cached file) and setVersion (sets the version to project.version)

You should use a build service probably.