hey, I have a dependency needed to be downloaded from a private repo

<https://packages.jetbrains.team/maven/p/teamcity-rest-client/teamcity-rest-client>

In

dependencyResolutionManagement

, when I declare plugin portal first, the builds keep failing saying can't find the lib and only 1 location, the plugin portal, searched

dependencyResolutionManagement {
    repositories {
        gradlePluginPortal()
        maven(url = "<https://packages.jetbrains.team/maven/p/teamcity-rest-client/teamcity-rest-client>")
    }
}

When I move the private repo to top, it works well. I wonder why gradle doesn't keep searching in the first scenario

maven(url = "<https://packages.jetbrains.team/maven/p/teamcity-rest-client/teamcity-rest-client>")
        gradlePluginPortal()

More strangely, this issue seem to happen only in my local, builds on CI look well

Could it be, that your local build cannot access the plugin portal or is going through some proxy or similar, that does not answer with 404 if something is not found but with some other error code? As long as a repository answers with 404, Gradle should try the next one.

it stopped searching right there

> Could not resolve all files for configuration ':monkey:compileClasspath'.
   > Could not find teamcity-rest-client-1.7.23.jar (org.jetbrains.teamcity:teamcity-rest-client:1.7.23).
     Searched in the following locations:
         <https://plugins.gradle.org/m2/org/jetbrains/teamcity/teamcity-rest-client/1.7.23/teamcity-rest-client-1.7.23.jar>

Yes, that would match with what I said

It's possible that you have to limit the contents of your private repository, e.g. taken from Gradle source:

repositories {
    maven {
        name = "Gradle public repository"
        url = uri("<https://repo.gradle.org/gradle/public>")
        content {
            includeGroup("net.rubygrapefruit")
            includeModule("flot", "flot")
            includeModule("org.gradle", "gradle-tooling-api")
            includeModule("org.gradle.buildtool.internal", "configuration-cache-report")
            includeModule("org.gradle.buildtool.internal", "gradle-ide-starter")
        }
    }
    //...
}

https://github.com/gradle/gradle/blob/master/build-logic-commons/gradle-plugin/src/main/kotlin/gradlebuild.repositories.gradle.kts

No, that is not necessary, it can be done, but it is not necessary if the repositories or in-between proxies or similar do not misbehave

but note that in their code they always put the catch-all

mavenCentral()

or

gradlePluginPortal()

last, so there must be something about that

The repositories are simply tried in the order they are defined. As long as a repository properly answers with 404 for not found, the next one is tried. If it misbehaves and answers with something else, a server problem is assumed and search stops for more reliable build result. So if you put the one with content filter after the "catch-all" how you name it, first the "catch-all" would be searched, then after returning 404 the other one is searched. If you have the other one first, always that one is asked first. If you do not have content filter then it is better to have the repository that has the most hits first. If you have a filter, but not configured it to be exclusively searched in that repository, then of course that one should come first.

It must be cache I tried the

--refresh-dependencies

flag and it works now