Gradle manager fails when using same version and library names

[atorrescogollo]

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.

34.20.4

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

github.com

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

No response

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

I never saw this working

Describe the bug

Dependency dashboard shows this when multiple versionRef entries reuse the same version entry:

WARN: Error updating branch: update failure

But this is actually an issue when looking up versions.

PoC (minimal reproduction)

Repo reference: https://github.com/atorrescogollo/renovate-issue-18825

// settings.gradle
...
            version("util.mapstruct", "1.5.2.Final")

            library("util.mapstruct", "org.mapstruct", "mapstruct").versionRef("util.mapstruct")
            library("util.mapstruct.processor", "org.mapstruct", "mapstruct-processor").versionRef("util.mapstruct")
...

The expected result would be like this:

Dependency Dashboard
------------------------
...
> Detected dependencies
gradle
    settings.gradle
       - `org.mapstruct:mapstruct 1.5.2.Final`
       - `org.mapstruct:mapstruct-processor 1.5.2.Final`

However, the actual result is:

Dependency Dashboard
------------------------
> Repository problems
      These problems occurred while renovating this repository.
      ```
      WARN: Error updating branch: update failure
      ```

> Errored
      These updates encountered an error and will be retried. Click on the checkbox below to force a retry now.

       - Update dependency org.mapstruct:mapstruct-processor to v1

> Detected dependencies
gradle
    settings.gradle
       - `org.mapstruct:mapstruct 1.5.2.Final`
       - `org.mapstruct:mapstruct-processor org.mapstruct` <--- This is wrong

Useful extra notes

It looks like the library entry somehow overwrites the version entry since it works if I change the order of the clauses to something like this:

            version("util.mapstruct", "1.5.2.Final")

            library("util.mapstruct.processor", "org.mapstruct", "mapstruct-processor").versionRef("util.mapstruct")
            library("util.mapstruct", "org.mapstruct", "mapstruct").versionRef("util.mapstruct")

Relevant debug logs

Logs

Copy/paste the relevant log(s) here, between the starting and ending backticks

Have you created a minimal reproduction repository?

I have linked to a minimal reproduction repository in the bug description

[viceice]

@zharinov any idea?

[atorrescogollo]

I just realized I put the preproduction repo as private. Now it's public: https://github.com/atorrescogollo/renovate-issue-18825

[viceice]

forked to https://github.com/renovate-reproductions/renovate-issue-18825

[viceice]

maybe blocked by

• feat(manager/gradle): rewrite and extend parser #18484

[viceice]

@atorrescogollo Please add a readme to the repo with expected and current behavior description

[atorrescogollo]

I realized that the problem is not related to versionRef. The issue is that the library is called with the same name as the version clause since changing one of them works. I'll update the issue description.

Regarding the #18484 PR, I run it against a test repo I have and it has the same issue.

[atorrescogollo]

@viceice I updated both the issue and the reproduction repo, so maybe would be a good idea to rebase your fork

[Churro]

PR #18830 adds a solution that will help for the current issue and also the "standard case" in which the default version catalog name libs is used.

In practice, it is possible to also specify version catalogs with different names. The current gradle parser won't be able find out prefix the correct name as it parses gradle files token-wise. At the time it pars a version catalog library(...), it won't be aware about the name of the catalog this library is embedded in.

To make this work for version catalogs with any name, I'm going to extend #18484 with a proper solution.