I'm working on refactoring a relatively large code base into smaller Gradle builds and/or modules trying to use the new Kotlin DSL and best practices for build scripts.

A rather premature question that I couldn't figure out from the docs is: Where should I centrally manage my repositories declarations? And how different constructs impact the resolution of said repositories?

Elaborating on that, I could declare repositories in the following ways:

1. Cross-configuration inside allprojects {} or subprojects {} in the build.gradle.kts file, which is discouraged according to this:

allprojects {
    repositories {
        ...
    }
}

subprojects {
    repositories {
        ...
    }
}

2. Use the dependencyResolutionManagement {} block in the settings.gradle.kts file:

dependencyResolutionManagement {
    repositories {
        ...
    }
}

3. Use the pluginManagement {} block in the settings.gradle.kts file:

pluginManagement {
    repositories {
        ...
    }
}

4. Use the buildscript {} block:

buildscript {
    repositories {
        ...
    }
}

I know that these declarations affect the available repositories in different parts of the build lifecycle in different ways. And that's the point. When should I use each one of them, or in some cases more than one of them? Do repositories declared in the dependencyResolutionManagement {} block interfere with repositories from where plugins are downloaded (those declared inside the pluginManagement {} block)? Are those repositories combined or overridden in any way, or are they completely separated sets of repositories?

CodePudding user response：

Generally speaking there are two different use-cases where Gradle uses repositories: dependency resolution and plugin resolution

For the repository you look up dependencies dependencyResolutionManagement is the most modern approach and is likely the best one to start with. It is available from Gradle 6.8 onward and was specifically created to have a single place to declare your repositores in.

The subprojects / allprojects approach gets you basically the same result with the difference that the values will be in-memory copy pasted onto all subprojects. However this likely only makes a difference if you use plugins that itself modify repository declarations. But I don't see any advantage either going this route in current Gradle versions.

The pluginManagement and buildscript repositories are for separate things and are not used to look up dependent libraries of your application. Instead those are used by gradle to look up libraries used for the build itself, i.e. if you delcare any Gradle Plugins that are not part of the Gradle core application they are resolved through those additional repositories.

However, since they are predefined to link to the Gradle Plugin portal you likely don't need to declare them at all. You could declare them if your company has any build plugins that are only available in internal repositories.

For completeness: pluginManagement is used for plugins declared in a plugin block while buildscript is used for libraries you import within the buildscript block (which might also be plugins)