I would hope that the Guava version doesn't affect Mockito somehow, but if it did, it would almost certainly mean that some kind of unusual bug is being triggered by our new Gradle Module Metadata.

There is probably not much we can do to investigate unless you're able to share a repo that reproduces the problem (or maybe a Gradle build scan if someone more experienced than I with Gradle has a look).

Thank you for quick response!
Here is sample project -https://github.com/amitlpande/test
In build.gradle if you change to any earlier version of guava (e.g. 32.0.1), the compilation succeeds.
Kindly let me know if anything is needed from my end.

Thanks,
Amit

Thanks! That's pretty interesting :)

It looks like, with 32.0.1, Gradle gives you mockito-core:3.8.0, as you requested. And with 32.1.1, Gradle gives you mockito-core:4.11.0, the version used by the separate artifact guava-tests (but not by guava) and specified in guava-parent both for 32.0.1 and for 32.1.1.

I wouldn't have expected the dependencyManagement section of guava-parent to affect the dependencies you see, at least not when guava doesn't use those dependencies itself. It does seem likely that this is fallout from Gradle Module Metadata. @jjohannes

You might be able to work around the problem immediately by migrating from Matchers to ArgumentMatchers (which I'm hoping is at least usually as simple as changing imports) and seeing if the rest of Mockito 4.11.0 is compatible with your project. Or you might be able to force Gradle to choose Mockito 3.8.0 again. (I assume that's easy, but I don't use Gradle enough to know how without looking it up.)

Thank you, yes forcing specific mockito version (in this case 3.8.0) helps resolve the issue.

Thanks for quick response!

This is unfortunate. The background here is that Gradle is based on composition, while Maven is based on inheritance. The concept of a "parent POM" does not exist in Gradle's model. Gradle can read a parent POM if it was published by Maven (effectively merging the POMs) but never publishes "parent POMs" itself.

If Guava would be published by Gradle, the versions would probably end up directly in the POMs – which are generated during publishing only as metadata (and not as project description).

What is possible is to use a parent POM – or more precisely the <dependencyManagemnt> block as a BOM (also called platform in Gradle) and integrate this via a dependency (doing composition instead of inheritance).

That's this part in the Gradle Metadata:

        {
          "group": "com.google.guava",
          "module": "guava-parent",
          "version": {
            "requires": "${pom.version}"
          },
          "attributes": {
            "org.gradle.category": "platform"
          }
        }

However, all entries are picked up by this approach. Also <scope>test</scope> – which is a detail I forgot about (see gradle/gradle#4765).

The better option would then maybe be to put the versions of the non-test dependencies directly in the Gradle Metadata and not do the dependency to guava-parent as BOM/platform. Maybe this can somehow be automated.

I could have a look at that.

Thanks. Would it work, then, for us to just stop using dependencyManagement in the parent pom at all? (We'd still keep the parent pom so that we can specify plugin configuration and list the other poms as modules.) Nowadays, we generally update deps in bulk with versions-maven-plugin, so it wouldn't really hurt for us to have to update 2-4 pom.xml files instead of 1.

Or does this also/instead need to be changed specifically in the Gradle metadata, as you'd offered to investigate?

And only after trying something else do I read carefully enough to get the point of #6654 (comment): We're getting away without version numbers in the Gradle metadata only because we're getting dependencyManagement from guava-parent. So, while getting rid of that dependencyManagement might fix the Mockito problem, it would break everything else :)

Or at least it would break everything else until @jjohannes is able to have a look at automating adding the versions to the Gradle metadata. But once that happens, do we actually gain anything by getting rid of dependencyManagement? Maybe my attempt to do so in #6657 is somehow of help if it simplifies that automation? But if not, I can probably just discard that change.

But, to the extent that this is "a problem with our Mockito dep," I can probably still solve it by removing Mockito from our dependencyManagement section. (I'm not sure I'd expect similar problems with any dep other than Mockito and maybe Truth, which both have removed APIs within the past several years.)

I'll release a new version of Guava to address the problem with the Mockito dep specifically.

I still don't have a full model for what's going on with dependency selection, and it seems from #6657 that we might be better off having dependency versions in the Gradle Metadata directly instead of pulling them in through guava-parent. So, despite closing this issue, I'm definitely interested in how to make that happen.

https://github.com/google/guava/releases/tag/v32.1.2 should fix this (and any similar problems that users might see with Truth). Thanks again for the report. Sorry that I'm using all your builds as a learning experience....

@cpovirk I think this works: #6664

Inside the POMs, move the versions into properties. Then use the properties in the module metadata.

That's probably the better solution. Feel free to take it from my draft PR and integrate it (if you also prefer that solution).

That looks excellent. Thank you.