👋 Hey everyone! I'm facing a perplexing dependency management issue that's driving me crazy 😕 I'm using Gradle to build my project, and I've configured it to use specific versions of the Netty dependencies using resolution strategy rules. However, there seems to be a discrepancy between what the Gradle dependency insight tool reports and what actually ends up in my fat JAR. 😱 I set overrides using the following configuration rules:

configurations.all {
  resolutionStrategy {
    eachDependency {
      if ("${requested.group}" == "io.netty") {
        if (requested.name.startsWith("netty-tcnative")) {
          useVersion("2.0.65.Final")
        } else {
          useVersion("4.1.109.Final")
        }
      }
    }
  }
}

Running

./gradlew app:dependencyInsight --dependency io.netty:netty-resolver-dns

gives me 4.1.109.Final as expected ✅

io.netty:netty-resolver-dns:4.1.106.Final -> 4.1.109.Final
\--- com.linecorp.armeria:armeria:1.27.3
     +--- com.linecorp.armeria:armeria-bom:1.27.3
     |    \--- compileClasspath

But when I open up the fat JAR and read the

pom.properties

for the dependency; I see the following:

From extracted/META-INF/maven/io.netty/netty-resolver-dns/pom.properties:

artifactId=netty-resolver-dns
groupId=io.netty
version=4.1.89.Final

How do I still have a 4.1.89 in there despite

dependencyInsight

indicating that I should have a 4.1.109.Final 🤯 This is my script for dumping the JAR deps btw -- https://gist.github.com/andrewloux/863434f893d29848f3a047f8f2093d90

hey 👋 Version alignment can be really tough! https://jakewharton.com/nonsensical-maven-is-still-a-gradle-problem/

Yep correct Adam! Here's the plugin https://github.com/johnrengelman/shadow

And I think that using constraints instead of a custom resolution strategy would be a better fit, although I don't know if it would help your specific problem, constraints are generally better https://docs.gradle.org/8.7/userguide/dependency_constraints.html#sec:adding-constraints-transitive-deps

Ah I see, does that just take more precedence that the dependency resolution rules?

basically, yes

Haha that would be ideal 😂 it's necessary in this case sadly

fair enough!

Ahh that link looks promising -- let me try it out

maybe the jvm-dependency-conflict-resolution plugin can help too The doc here mentions

io.netty:netty-common