Hello. I am developing a plug-in that provides a series of gradle tasks. The logic inside of the gradle tasks requires some dependencies that live inside of a specific maven repository. I want to allow projects to add the plug-in but not require them to also configure the specific repository for the dependencies that are required for the plugin's tasks to do the work. In other words, I want the plug-in to add the repository that is required for the tasks to work to the project automatically. Is this at all possible?

Yes, a plugin can add repositories. But (and this is a big but!) it's possible for users to prevent plugins from adding custom repositories. https://docs.gradle.org/8.6/userguide/declaring_repositories.html#sub:centralized-repository-declaration

// settings.gradle.kts

dependencyResolutionManagement {
    repositoriesMode = RepositoriesMode.FAIL_ON_PROJECT_REPOS
}

Thanks for the response. I'm not quite sure this solves my issue. Let me try a different explanation: I am writing a plug-in that does two things: 1. Adds a repository and implementation dependency to the consuming project. 2. Provides gradle tasks to the consuming project. When those gradle tasks run, the plug-in itself also uses the same implementation dependency that it asked the consuming project to add. It uses the same dependency to do some code generation. The implementation dependency being provided to the consuming project and also needed by the plug-in itself lives inside of the custom repository

ahh right, okay

Whatever you do, please really strongly consider not to add repositories anywhere automatically, better with an opt-in or at least with an opt-out. Unless the whole topic is about some internal plugin. But for a public plugin it is a big no-go to add repositories unasked. For example quite some corporate rules demand to only use internal repository servers which would mean your plugin cannot be used if it adds repositories unconditionally. If such a bootstrap plugin Adam suggested basically just configures those repositories, that would indeed count for me as opt-in, as you can choose to not apply it but provide the dependencies through some own repository or manually configured or whatever. A consuming build should always have the last say on where dependencies are or are not consumed from.

Yeah this is internal corporate

the only other option I can think of is to create a custom Gradle distribution that packages your plugin, so no repo is needed https://docs.gradle.org/8.6/userguide/organizing_gradle_projects.html#sec:custom_gradle_distribution