From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

overriding `toString`  so it uses `myProp.get().toString()`

I have difficulty predicting what Gradle can serialize into the configuration cache and what it can't

If you want to force that value to be changed, use `ValueSource` API

Is the basic concept of `ValueSource` that the `obtain()` method is called on each build, and the `ValueSource` implementation deals with things like caching? For example, I can shell out to an external process, cache what it returns, and invalidate the cache when an input changes that I know about (but I have to handle all this myself instead of Gradle tracking it)

Whether `project.version` is serializable should be irrelevant for configuration cache.
Iirc the config cache stores the tasks and their configuration / state.
and a task also is not allowed to access the project at execution time.

Regarding `ValueSource`, if you know the external processes delivers the same output for the same input, you can of course add some caching. The `ValueSource` is indeed evaluated on each build and if the value changes, the cache entry is discarded. In that case, the value source is even calculated a second time during normal configuration phase.

&gt; In that case, the value source is even calculated a second time during normal configuration phase.
Interesting; is that deliberate or just a bug?

I guess it's intended, but actually I don't find this in the docs. Maybe just someone mentioned it. So now I'm not sure anymore whether it is the case and whether it is intended.

Ah, stumbled upon it again.
<https://docs.gradle.org/7.5/userguide/configuration_cache.html>
&gt; In both approaches, if the value of the provider is used at configuration time then it will become a build configuration input. The external process will be executed for every build to determine if the configuration cache is up-to-date, so it is recommended to only call fast-running processes at configuration time. If the value changes then the cache is invalidated and the process will be run again during this build as part of the configuration phase.
This is about running processes, but the second of the "both approaches" is using a `ValueSource`.