Difference in resolution between Windows & Linux

I’m trying to enable dependency locking, but running into an issue with Linux choosing a different set of artifacts from Windows. One such example is below.

Windows:

\modules\Utilities>gradle dependencyInsight --dependency jackson-annotations

> Task :Utilities:dependencyInsight
com.fasterxml.jackson.core:jackson-annotations:2.13.4
   variant "compile" [
      org.gradle.status              = release (not requested)
      org.gradle.usage               = java-api
      org.gradle.libraryelements     = jar (compatible with: classes)
      org.gradle.category            = library

      Requested attributes not found in the selected variant:
         org.gradle.dependency.bundling = external
         org.gradle.jvm.version         = 8
   ]
   Selection reasons:
      - By constraint : dependency was locked to version '2.13.4'
      - By ancestor

com.fasterxml.jackson.core:jackson-annotations:{strictly 2.13.4} -> 2.13.4
\--- compileClasspath

com.fasterxml.jackson.core:jackson-annotations:2.13.4
\--- com.fasterxml.jackson.core:jackson-databind:2.13.4.2
     +--- compileClasspath (requested com.fasterxml.jackson.core:jackson-databind:{strictly 2.13.4.2})
     \--- com.microsoft.azure:msal4j:1.13.8
          \--- compileClasspath

(*) - dependencies omitted (listed previously)

Linux:

 Utilities]$ gradle dependencyInsight --dependency jackson-annotations

> Task :Utilities:dependencyInsight
com.fasterxml.jackson.core:jackson-annotations:2.13.4
   variant "apiElements" [
      org.gradle.category            = library
      org.gradle.dependency.bundling = external
      org.gradle.libraryelements     = jar (compatible with: classes)
      org.gradle.usage               = java-api
      org.gradle.status              = release (not requested)

      Requested attributes not found in the selected variant:
         org.gradle.jvm.version         = 8
   ]
   Selection reasons:
      - By constraint : dependency was locked to version '2.13.4'
      - By ancestor

com.fasterxml.jackson.core:jackson-annotations:{strictly 2.13.4} -> 2.13.4
\--- compileClasspath

com.fasterxml.jackson.core:jackson-annotations:2.13.4
+--- com.fasterxml.jackson:jackson-bom:2.13.4
|    +--- compileClasspath (requested com.fasterxml.jackson:jackson-bom:{strictly 2.13.4})
|    +--- com.fasterxml.jackson.core:jackson-annotations:2.13.4 (*)
|    +--- com.fasterxml.jackson.core:jackson-core:2.13.4
|    |    +--- compileClasspath (requested com.fasterxml.jackson.core:jackson-core:{strictly 2.13.4})
|    |    +--- com.fasterxml.jackson:jackson-bom:2.13.4 (*)
|    |    \--- com.fasterxml.jackson.core:jackson-databind:2.13.4.2
|    |         +--- compileClasspath (requested com.fasterxml.jackson.core:jackson-databind:{strictly 2.13.4.2})
|    |         +--- com.microsoft.azure:msal4j:1.13.8
|    |         |    \--- compileClasspath
|    |         \--- com.fasterxml.jackson:jackson-bom:2.13.4 (requested com.fasterxml.jackson.core:jackson-databind:2.13.4) (*)
|    \--- com.fasterxml.jackson.core:jackson-databind:2.13.4.2 (*)
\--- com.fasterxml.jackson.core:jackson-databind:2.13.4.2 (*)

(*) - dependencies omitted (listed previously)

The Linux version transitively includes the jackson-bom, which is not included on Windows. This difference is causing the build to fail if the lock files were created on the other platform.

I don’t have any OS platform dependent configurations declared, so I’m having trouble seeing what’s causing this difference. I think it’s related to the variant model, but since this is Maven POMs, it’s supposed to be all automatically translated.

How can I get these two to resolve the same?

Thanks.

Could you maybe provide build --scans of those two runs?

Unfortunately, I can’t share build scans as it has internal product info.

However, while trying to replicate the issue with a smaller project set that I could share, it didn’t replicate. Additionally, I tried the full configuration on another Windows computer the issue did not replicate. Which makes the issue environmental, somewhat.

I’m still working to find a minimal configuration that produces the error. For clarity, manual inspection of the dependency POMs says that the Linux configuration is the correct one.

The environmental issue is due to some bad data in the local Maven repo cache. Clearing that out fixed the original project set.

Thanks.

Yeah, that would have been my next guess.

The mavenLocal() repo is broken by design in Maven and should never be used persistently in a build unless really needed, and even then only with a repository content filter that defines exactly which dependency to use from it if really necessary.