Hunt strategy change for Maven repos is not how build systems which use Maven repositories behave

[JakeWharton]

How are you running Renovate?

Mend Renovate hosted app on github.com

If you're self-hosting Renovate, tell us what version of Renovate you run.

No response

If you're self-hosting Renovate, select which platform you are using.

None

Was this something which used to work for you, and then stopped?

Placeholder value, please select the correct response from the dropdown

Describe the problem

This ticket and this PR changed the strategy of resolving Maven dependencies from 'merge' to 'hunt'. The citation on the issue is that is how Maven (the build tool) purportedly behaves. This is describing how full Maven coordinate triples are resolved, not which versions are available in a repo, and as a result you are now going to miss dependency updates from artifacts which changed their Maven repo host.

Take, for example, the official Android Gradle plugin artifact whose coordinates are com.android.tools.build:gradle. Early on, Google published this to Maven Central as seen here: https://repo1.maven.org/maven2/com/android/tools/build/gradle/. Eventually, however, Google began publishing at a higher rate and higher quantity so they launched their own Maven repo hosted at maven.google.com. You can see the newer versions of the Android Gradle plugin artifacts here: https://maven.google.com/web/index.html#com.android.tools.build:gradle. Notice how the artifacts on Maven Central stop at 2.x.x and those on Google Maven start a 3.0.0.

The majority of artifacts an Android developer will consume come from Maven Central and so it usually appears first in the repo list. This ensures two things:

1. We're not sending Google data on which artifacts are in use by requesting them from Google first. And,
2. This speeds up your build because the majority of artifacts hit on the first repo. If the Google repo was first they would 404 and we would have to try again elsewhere.

As a result of this change, many repos stopped seeing updates. For example, here's a PR that got a new version before the above change was deployed. And here's a Dependency Dashboard whose job ran after the deploy and thus seems stuck on 8.1.1 despite 8.1.2 being out.

The Renovate job for that repo shows that it only checks Maven Central and never the Google Maven repo:

      {
        "datasource": "maven",
        "deps": [
          {
            "currentValue": "8.1.1",
            "currentVersion": "8.1.1",
            "datasource": "maven",
            "depName": "com.android.tools.build:gradle",
            "depType": "dependencies",
            "fileReplacePosition": 254,
            "fixedVersion": "8.1.1",
            "homepage": "http://tools.android.com/",
            "managerData": {
              "fileReplacePosition": 254,
              "packageFile": "gradle/libs.versions.toml"
            },
            "packageName": "com.android.tools.build:gradle",
            "registryUrl": "https://repo.maven.apache.org/maven2",
            "registryUrls": [
              "https://repo.maven.apache.org/maven2",
              "https://dl.google.com/android/maven2/",
              "https://plugins.gradle.org/m2/"
            ],
            "sourceUrl": "https://android.googlesource.com/platform/tools/base",
            "versioning": "gradle",
            "warnings": [],
            "updates": []
          },
 ⋮
DEBUG: Looking up com.android.tools.build:gradle in repository https://repo.maven.apache.org/maven2/
 ⋮
DEBUG: Found 76 new releases for com.android.tools.build:gradle in repository https://repo.maven.apache.org/maven2/

If I manually bump the version to 8.1.2, the build will successfully resolve the artifact. This is because Gradle will attempt to fetch it first from Maven Central and fail, it will then move on to Google Maven, my second configured repo, and attempt there.

Ultimately, when I read the Maven build tool link referenced in the original ticket I actually think this change is in error. Because that documentation is detailing the behavior when resolving a Maven coordinate triple (i.e., a groupId and artifact with a version). It is not detailing how it resolves the maven-metadata.xml files which provide a list of versions of a groupId+artifactId pair.

You can reproduce this with a repo that contains a single build.gradle file with the following contents:

apply plugin: 'java'

repositories {
  mavenCentral()
  google()
}

dependencies {
  implementation 'com.android.tools.build:gradle:8.1.1'
}

Note that this project builds (by running gradle build proving the resolution algorithm checks both repos).

I made a minimal reproducer for the Maven build tool as well. Put the following into a pom.xml in a repo:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>example</artifactId>
  <version>1.0-SNAPSHOT</version>
  <repositories>
    <repository>
      <id>maven-central</id>
      <url>https://repo1.maven.org</url>
    </repository>
    <repository>
      <id>google-maven</id>
      <url>https://maven.google.com</url>
    </repository>
  </repositories>
  <dependencies>
    <dependency>
      <groupId>com.android.tools.build</groupId>
      <artifactId>gradle</artifactId>
      <version>8.1.1</version>
    </dependency>
  </dependencies>
</project>

This project also builds (using mvn compile), proving that Maven (the build tool) will check both repositories despite the first containing a set of artifacts matching the groupId+artifactId but not having a matching version.

Both of these projects when run with Renovate will not see the 8.1.2 upgrade. However, manually bumping the dependency to 8.1.2 will successfully build in both.

With this, I hope that I've convinced you that the linked commit above should be reverted, or at least changed to a strategy which honors full coordinate triples in the first Maven repo they're found in, but still checks all Maven repos for those sets of triples.

Relevant debug logs

No response

Have you created a minimal reproduction repository?

I have linked to a minimal reproduction in the description above

[rarkins]

We may need a more complex approach than simply changing mergeStrategy from hunt to merge. One challenge was that Renovate in many cases was searching non-Maven Central repositories unnecessarily, leading to increased search times, increased load on that server, etc. What would be the solution in that case? e.g.

• In such cases users should use packageRules to manually override registryUrls to remove the second repo when it's not needed, or
• We need to make hunt/merge user-configurable, like registryUrls?
• In such cases users should configure their maven or gradle better so that it references the alternative registry only when necessary, and not for all?

Cc @Churro

[rarkins]

We will revert this change back to how it was in v36 and provide instructions for those who wish to minimize requests to internal servers

[thomaszub]

@rarkins: When will the v36 approximately be released? Asking for a another developer who I am supporting with Renovate.

[rarkins]

It's v38 next and will be before end of year, maybe end of November

[rarkins]

We plan to release it in v37 instead: #26013

[eygraber]

Does v37 correlate with renovateVersion in the job logs? If so I'm still seeing the issue where com.android.tools.build:gradle matches in maven central and never finds the versions from maven.google.com (job log.

[rarkins]

If you look in the linked PR you'll see:

If you look in a recent Renovate app log you'll see:

In other words, the app is not yet running the latest so needs to be updated before the functionality change is "live". This should hopefully happen on Sunday

[jonesbusy]

Hunt strategy was also causing conflict with release/snapshot repositories order : #25294

Thanks for the revert

[aikebah]

@rarkins I recently discovered this ticket after observing item 1. of the opening post in one of my debug logs (self-hosted renovate). I don't see that addressed in the context of this ticket. Any plans on fixing up hammering Maven Central with lots of useless requests? The IS NO index.html, there is an HTML-page 'directory listing' served if you browse the folder location, so the index.html should not be added to the URL.

E.g.
https://repo.maven.apache.org/maven2/com/android/tools/build/gradle/ lists the versions of the com.android.tools.build:gradle hosted on maven central and is the HTML that should be parsed when you don't want to trust on maven metadata, but the current code will instead try to retrieve and parse https://repo.maven.apache.org/maven2/com/android/tools/build/gradle/index.html which will always yield a HTTP-404

That is... to resolve item 1. at

renovate/lib/modules/datasource/maven/index.ts

Line 146 in a13090c

const indexUrl = getMavenUrl(dependency, repoUrl, 'index.html');

'index.html' should be changed to '' to retrieve the package index page from Maven Central.

[rarkins]

PR welcome. Otherwise please start a new discussion with your idea

[rarkins]

Locking this as I'd like any new discussions on the topic to be in a new github discussion