This message was deleted.

For the repo side of this, I've found using

apply(from = repositories.gradle.kts)

is the easiest way to do this without going circular dependencies all the way down. One example here

Would that break configuration caching?

Maybe?

Is that for

pluginManagement { repositories { ... } }

or

dependendencyManagement { repositories { ... } }

?

@Vampire we have a very long thread somewhere about this but I think it works with

pluginManagement

too in KTS (but maybe not in Groovy)

Want to configure some internal plugins and make them available as precompiled gradle scripts so will be declaring it as a dependency in my buildSrc using

dependendencyManagement

(assuming that will make these plugins available to all subprojects), and also as a repository in

dependencyManagement

for all my subprojects.

Then instead of a script plugin as Martin suggested if you don't want that or if it is not CC compatible, you should be able to add your new project that is just for that extension function either to the buildscript classpath of the settings plugin explicitly, or by having a dummy settings plugin that you apply to the settings script to get the classes with the extension on the buildscript classpath. The settings plugin does not need to do actions (or it could actually add those repositories already) and you will

includeBuild

that build within

pluginManagement { ... }

.

Hmm, i'm trying this but gradle complains that I can't add

project

dependencies to the buildscript classpath.

Not a project dependency. You cannot use something you build in the build that builds it. It should be in a separate included build via composite build.

Ah, if i includeBuild in

pluginManagement

, would it automatically get added to buildscript classpath?

No, you still need to add it by coordinates or dummy plugin