This message was deleted.

Best practice is to not do it. Or at the very least make it optional. Plugins should not unconditionall add repositories. Or you for example break company guidelines that enforce to use only internal repositories or break builds that use

FAIL_ON_PROJECT_REPO

.

Make sense. I think that’s why I can’t see this happens in public plugin.

It happens in some public plugins, but they are misbehavers in my opinion 🙂

Would this not be a valid usecase for build convention plugins? Or perhaps commercial tools that have their own repository to pull in dependencies from.

Would this not be a valid usecase for build convention plugins?

Sure, if you want to have it in some private plugin because it is the right thing to do for you in your builds, why not. I'm talking about best practices and public plugins. Many companies have the rule that you must only use internal repositories for various reasons, for example reliability if the external service has an outage or internet access has an outage, supply chain security by preventing to consume compromised external repositories, and also by preventing cross-repository deployment attacks, .... Additionally, I for example want even in my personal projects to know and control which repositories are used. I usually declare repositories in the settings script using

pluginManagement

and

dependencyResolutionManagement

(this can of course also be done in a settings convention plugin) and configure the mode to

FAIL_ON_PROJECT_REPOS

. I expect this to also be done by the companies with the above mentioned rules. Such builds will hard fail if any plugin tries to add a repository.

Or perhaps commercial tools that have their own repository to pull in dependencies from.

All that I said above. This is bad practice, especially if it is hard-coded and not configurable. The user of the plugin should always have the option to configure an own repository (mirror).

Also can you elaborate on how can adding repositories(via a plugin) be made optional?

Like any other logic too. For example by configuring some extension. Or by calling some method in some extension like

addDefaultRepository()

if the default is to not add it. Many ways are thinkable. Even a Gradle property would probably do. Almost anything is better than hard-coded adding it automatically. Or just don't add it and document that the user has to add it in his build.

Ah got it. Makes sense, I imagined a gradle api like the dependency substitution apis 🙂 Yes this makes sense. Public plugins enforcing repositories would not be ideal. Thank you for the detailed explanation!