Difference in resolution between Windows & Linux

Help/Discuss
1

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.

2

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

3

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.

4

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

Thanks.

5

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.