Skip to content

Overridden Dependency Version Rule

Jon Schneider edited this page May 12, 2016 · 3 revisions

The overridden dependency version rule is an example of a simple dependency hygiene rule.

To apply the rule, add:

gradleLint.rules += 'overridden-dependency-version'

Often, latest version conflict resolution of transitive dependencies, forces, and resolution strategies can affect dependency versions in ways that developers do not expect. This rule ensures that your first order dependency versions are specified in a way that is consistent with what was actually resolved. This is a "principal of least surprise" rule.

The rule considers whether a particular version constraint could be satisfied by the actually resolved version, but without considering repository state.

configurations.compile {
    resolutionStrategy {
        force 'com.google.guava:guava:18.0'
    }
}

dependencies {
    compile "com.google.guava:guava:$version"
}

The rule deals with the following cases for $version. In every case where a violation is thrown for this example, the auto-fix rule would change the dependency to com.google.guava:guava:18.0.

  1. Fixed. $version != 18.0 violates the rule.
  2. Subversion. If $version == 18.+, the resolved version of 18.0 matches so no violation is thrown. $version == 19.0 violates the rule.
  3. Range. $version == [16.0, 17.0] violates the rule.
  4. Latest. $version == latest.release does NOT violate the rule, even though a 19.0 version of guava exists because the rule does not consider repository state, but only whether a resolved version could theoretically satisfy the constraint given some repository state.

Interaction with nebula.dependency-lock

The most recent version of the nebula.dependency-lock plugin uses a resolution strategy to lock dynamic constraints to a specific version. Since dependency lock may have locked a latest constraint to the latest version at the time that the lock was generated and a newer version could have been released since, the rule's treatment of latest constraints does not interfere with dependency locking.