This message was deleted.

Basically we have repository blocks everywhere, including in the

settings.gradle.kts

files (

pluginManagement

,

dependencyResolutionManagement

) as well as

buildSrc

and

includeBuilds

.

fwiw, i use plugins to apply standard company repo info to project dependencies, and for the pluginManagement repos, a custom gradle wrapper that has an init script that does it

Can you explain

a custom gradle wrapper that has an init script that does it (edited)

a little more?

If you want to do it in

build.gradle.kts

scripts just add a settings plugin or normal project plugin in the root project that declares

fun DependencyHandler.company() = maven { ... }

in default (root) package to bring it to the classpath. You also could add the company repo same way in the settings via

dependencyResolutionManagement.repositories { ... }

to avoid duplicating it in each build script. Delivery vectors are the same: a settings plugin or an init script classpath. If you want to use it for

pluginManagement.repositories

then only an init script classpath is left. Though the init script could be delivered via local (for each developer)

~/.gradle/init.d

or a custom distribution's

init.d

. YMMV but I tried approach with custom gradle distribution but eventually just wrote an open source plugin, published it to the plugin portal and it automagically adds private repo to both

pluginManagement

and

dependencyResolutionManagement

with simple application of the settings plugin (among other opt-in things like adding version catalogs and plugin declarations to the settings'

plugins

block from simple properties file). If interested in the details take a look at https://gradle-community.slack.com/archives/CA745PZHN/p1657944560799889

As for custom wrapper distribution, see https://docs.gradle.org/current/userguide/distribution_plugin.html it's another option if publishing a settings plugin to the public gradle plugin portal is not feasible for you