oh come on... why is `apply { from(...) }` not available in `buildscript` section - obviously I mig...

# gradle

[darkmoon_uk]

oh come on... why is apply { from(...) } not available in buildscript section - obviously I might want to apply some common configuration from a file at the earliest point of evaluation. Are the Gradle authors trying to be awkward?? 😠

[octylFractal]

If you want something at the earliest point of eval, try using settings.gradle(.kts) instead

[octylFractal]

but typically, just applying at the top* of the project file is early enough

*post buildscript, plugins, etc.

[darkmoon_uk]

Thanks but it's not working - I'm just trying to load my dependency version variables from a properties file (into extras) so they can be used in both buildscript and project evaluation - hardly an exotic requirement.

[darkmoon_uk]

I guess using Kotlin DSL is still 'early adoption'... apologies for the frustration, it's just not something I expected to get so hung up on!

[octylFractal]

in this case, you're probably better off trying buildSrc

this has nothing to do with Kotlin DSL, it's a restriction in both DSLs since the code runs at a special time, with special evaluation restrictions

[darkmoon_uk]

Nice I didn't know about `buildSrc`; this could be the answer for me, so that I can call a common properties loading function across my projects.

[darkmoon_uk]

Thanks 👌

[DALDEI]

For a global consistent properties handling mechanism that works in settings as well as build.gradle(.kts) and doesn't require a buildSrc checkout the properties plugin
https://github.com/stevesaliman/gradle-properties-plugin
To get it to work in settings takes some effort but its well documented. There are more ways to inject properties then I had thought possible -- a main feature of the plugin is 'environment specific' property sets.

I have used this for years, although slowly weaning myself off of it as I don't make as much use of properties as I used to.

[DALDEI]

I have moved to creating a separate project (I call it 'core-dsl') for cross-project setting like Versions, and common tasks. This is the next step up from a buildSrc when you get to the point of having multiple projects and dont want to duplicate the buildSrc everywhere