I have a question about best practices for loading properties from a custom file. I was thinking that it might be better to move this functionality to the settings.gradle.kts file in a gradle.lifecycle.beforeProject scope, which would be during the initialization phase instead of the configuration phase. This would make it accessible to each project without having to call rootProject (having some weird condition where findProperty isn't finding something in the rootProject from a subproject). But I was thinking this would alleviate any race conditions when moving to Isolated Projects, when they configure in parallel. Is this a better way to load a separate property file? And what impact would this have on performance/caching?

If I understand this correctly, that is what I would do nowadays if I want to avoid loading the file multiple times. Option 1 (I think this is what you suggest) • Load file in settings.gradle and put content into an object that you register as extension in all projects in

gradle.lifecycle.beforeProject

• Then you can access all information through that single-instance extension in all subprojects. (There should be no issue with isolation, because the loading itself is done in the init phase which runs before the parallel configuration of projects.) • Disadvantage: potentially more boilerplate/complexity (creating extension, registering it in one place, accessing it in anothers) Option 2 • Load the custom properties individually in each subproject • Setup can be simpler without extension -> load properties and use them directly • Disadvantage: Multi loading of the same file. Gradle may still only load once if you load through

providers.fileContents

(not sure if that is true, would like to know). I am usually doing Option 2 but on the long run Option 1 feels cleaner.

Another option, have a shared build service that does the file parsing and that you ask for the properties.

that is an interesting thought, as preventing the configuration cache from being invalidated could be more effective. A side thought: I'm actually surprised that Gradle doesn't currently detect (or maybe they plan to) see if you access a variable. I am currently able to send a

-PvariablethatIneveruse=whatever

that I never use and it affects the configuration cache. I would have hoped that it keeps track of that usage as inputs, but I guess it is much simpler than that. One issue I ran into with Option 1, I was unable to cache the data outside of the scope

gradle.lifecycle.beforeProject

, so unclear how to prevent reloading for each project. I got a serialization issue.

I got a serialization issue.

Your

j

is a top-level property in the script, that practically means it is a property of the instance of the class implementing the Script logic and that instance cannot be serialized. You need to break this chain, for example like

object DoesNotNeedAScriptReference {
    var j = 1
}
gradle.lifecycle.beforeProject {
    println("Configuring project ${DoesNotNeedAScriptReference.j++}: ${this.path}")
}

interesting, didn't realize it became part of the class instance

I am currently able to send a

-PvariablethatIneveruse=whatever

that I never use and it affects the configuration cache.

As far as I remember there is a ticket to improve this somewhere, but I don't find it right now.

glad to hear that, that would be a nice improvement