1

I came to set of projects built by Gradle, where upgrading only happens when something stops building, or an infamous CVE appears. Which leads to very wild range of incompatible versions, which just happen not to collide by coincidence (not triggering a call to a missing method, etc.). The in-house project dependency tree is quite deep, and fixing all of them is hard.

In one project, I set a version of Log4j API. This artifact breaks binary compatibilty quite often, and I hit one between 2.17 and 2.18.

A transitive dependency says it wants 2.18, so Gradle obeys and ignores the explicitly set project's version, as documented here.

I find this a bad strategy in general, and would like to switch to a nearest-highest, which would effectively always follows the version the project demands explicitly, or the highest of the same distance.

But I see that Gradle only has a quite limited choice in ResolutionStrategy, from which I can only use force, in a verbose way:

allprojects {
    // Log4j breaks binary compatibility even in the API, so we need to intervene.
    // Replacing Log4j is highly recommended!
    configurations.configureEach {
        resolutionStrategy {
            force 'org.apache.logging.log4j:log4j-api:2.17.2'
        }
    }
}

In my particular case, it is a downgrade, so I could use strict. But at the same time, that would restrict a consumer of the resulting artifact, which I do not want - if "they" manage to align versions to 2.18 in their runtime, they should be able to.

Is there some Gradle plugin that would add more options for resolutionStrategy? Something like,

    resolutionStrategy {
        useNearestHighest()
    }
Ondra Žižka
  • 43,948
  • 41
  • 217
  • 277

0 Answers0