This message was deleted.

I personally prefer the delegates' usage over string-y methods generally. The

this@Build_gradle.

that is necessary is a bit unnice, but that's because those extensions have same-named properties. A rename e. g. of the property could maybe mitigate that. Actually, I would probably not have those values in the properties file, but directly in the build script if I were to write the build script myself unless I want to be able to override them via

-P

or the user-specific properties file. But I guess this is that the typical consumer does not need to read and understand and modify the build script, but just do the configuration in the properties file.

Thanks for sharing your thoughts, @Vampire. The purpose of moving all potentially modifiable values in the

gradle.properties

file is indeed to keep the configuration as simple as possible. As I understand the benefit of having each variable defined separately – you can define its type explicitly, no magic involved… This approach produces a verbose header to the file when you have ten properties. I could probably turn into this direction faster if this would be possible:

val platformPlugins: List<String> by project

but:

* What went wrong:
class java.lang.String cannot be cast to class java.util.List (java.lang.String and java.util.List are in module java.base of loader 'bootstrap')

Yeah, no, there is no auto-coercion into other types. It also gives "extra" properties which could be any type so there a different type would make sense. For the properties from the properties file, they are always

String

unless maybe you invent an own delegation method that would support such type coercions. So in this case the type declaration is not really the most relevant. Opposed to your solution the new one would complain if a property is not set though. And I personally just prefer to have such delegates, to for example easier be able to make renames and not forget a place where the name is used as

String

and so on. The approach with the delegates does not have to be made as "header", you can also declare the properties near the place where you use them instead of all in the beginning.