This message was deleted.

I'm going to try to specify

gradlePluginPortal

like:

gradlePluginPortal {
  content {
    includeGroupByRegex("com\\.gradle.*")
  }
}

and then specify it again in my extension function without the

includeGroupByRegex

which I'm hoping adds a new repository and doesn't override the original one

However that means that

gradlePluginPortal

will be the first repository used to look for plugins, which I understand is not desirable

For this you can use

exclusiveContent

: https://docs.gradle.org/current/userguide/declaring_repositories.html#declaring_content_exclusively_found_in_one_repository

Is there a way to specify that an added repository be checked last when looking for dependencies?

Not that I'm aware of. They are checked in order of addition, you can just use content filters to only resolve specific things but not others.

I'm adding repositories outside of the settings'

pluginManagement.repositories

block (using an extension function that comes from a plugin, which can't be used in the block because it isn't in the classloader yet).

That's fine as long as those repositories do not contain a settings plugin you want to apply.

However that means that

gradlePluginPortal

will be the first repository used to look for plugins, which I understand is not desirable

Why is that not desirable? That's indeed the default case, plugins are only searched in that repository if you do not specify any explicitly.

and then specify it again in my extension function without the

includeGroupByRegex

which I'm hoping adds a new repository and doesn't override the original one

Sounds like a viable plan, yes. And if it does not work, try it with

maven("the url of the plugin portal")

if it does not work with the accessor.

Is there any way to use a remote artifact in the

pluginManagement.repositories

block?

I don't think so.

My use case is that I have a complicated set of repositories that I declare, and I use them in multiple projects. I'd like to make an extension function in a remote artifact that sets up all of the repositories for me, so I can reuse it in all of my projects.

If feasible, you could instead use an init script. For example have a custom distribution for your projects, or at least customized Gradle wrapper scripts that included a custom init script, that then can add the external dependency to its classpath and use the utility function in

beforeSettings { ... }

.

> However that means that

gradlePluginPortal

will be the first repository used to look for plugins, which I understand is not desirable

Why is that not desirable?

I thought the recommendation was to put

mavenCentral

before it.

If feasible, you could instead use an init script.

Sounds like that would be the way to go, just not feasible for my scenario 😅 Thanks!

I thought the recommendation was to put

mavenCentral

before it.

Depends on whom you ask and the situation you are in. The point is, that the plugin portal redirects to JCenter for things it does not have itself. And JCenter forwards to Maven Central it does not have itself. So if JCenter again has an outage, you can only resolve things directly on the plugin portal, but neither things on JCenter, nor things on Maven Central. If you put Maven Central first, then only the things exlcusively available on JCenter are not available when JCenter has an outage. So for things that are important not to have 1-2 day non-buildable time just because JCenter again has an outage while JCenter is not actually needed as all required things are on plugin portal or Maven Central, it might make sense to put Maven Central before it. For my personal projects I usually don't care if they are not buildable for 1-2 days on machines that do not have the required stuff in the cache already. For important projects like projects at work, we do not use any public repositories anyway as it could always be that they have an outage or the internet breaks down or whatever, so there we have a caching proxy like a Nexus Repository Manager server anyway and only that is used in the projects, so we are not affected by any downtimes anyway unless we need new libraries.