This message was deleted.

The only workaround I found is: (Thanks Vampire) • Create the funciton in my

pluginManagement

from

settings.gradle.kts

• Save the result in my ext gradle object • Get the ext property in

build.gradle.kts

Of course, this is very dirty, but wanted to double check that I would need to follow this approach if I don’t want to duplicate the function.

it’s possible in a variety of ways. For example, setup buildSrc and define the function in

buildSrc/main/kotlin/utils.kt

Adam, not in those particular blocks

Unless you have an ancient Gradle version where

buildSrc

is still done before the setting script evaluation, but that is looong ago 😄

IMO you should treat those blocks as very limited declarative DSLs, not for general code anyway

Maybe you could hack something with an init script, or of course with a custom distribution as you can then completely change Gradle in any way you want. 😄

https://docs.gradle.org/8.0/userguide/plugins.html#sec:constrained_syntax limiting the syntax used in the

plugins

block results in faster script compilation, and that could be extended to the other blocks as well

ah okay, my mistake

Unless you have an ancient Gradle version where

buildSrc

is still done before the setting script evaluation

Yup, from what I’ve read this used to work previous to gradle version 6.0

IMO you should treat those blocks as very limited declarative DSLs, not for general code anyway

Absolutely. Don’t want to add much boilerplate. I just want to add a dependency/repo or not based on the current flavor.

a buildSrc util function works for

buildscript

but not

pluginManagement

Yes! I had tested it, thanks for double checking,

pluginManagement

goes separately

Maybe you could hack something with an init script

Trust me, I tried!

maybe tinkering with a custom Gradle distribution? https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:custom_gradle_distribution

possibly move the logic inside a plugin to include/exclude other stuff as appropriate? (unclear what you wish to conditionally include)

I just want to add a dependency/repo or not based on the current flavor.

that doesn't sound right, this these configure the classpath for the buildscripts as a whole

My bad, I meant repository for

settings.gradle.kts

& classpath for

build.gradle.kts

root

"based on the current flavor" is the part I'm concerned by

Hmmm let’s say this is what happens: If I’m in a specific flavor we add a few extra

classpath

and thus we add some repositories in

settings.gradle.kts

so these classpath can be found

perhaps something isn't coming across, but if by "flavor" you mean Android product types/flavors or Gradle build feature variants, no, that doesn't make sense

Ah I’d like to explain it if I understood it at 100% what’s going on… But basically yeah I mean product flavors from Android. But at root level there are no flavors and this is set from

gradle.properties

in order to configure it. Clearly by writing it, I see it doesn’t seem to be right..

I think it’s easy to get mixed up when we’re using a JVM build tool to build JVM projects. If Gradle was written in Python, then (hopefully) it would make more sense why trying to add JVM dependencies to a Python util isn’t needed :)