Customizing plugin behavior

The plugin provides a dependencyAnalysis {} extension (com.autonomousapps.DependencyAnalysisExtension) for configuration.

Customizing which variants to analyze

If your Android project uses flavors or custom build types, you may wish to change the default variant that is analyzed. By default, this plugin will analyze the debug variant for Android, and the main source set for Java. To customize this, add the following to your root build script.

root build.gradle

dependencyAnalysis {
  setVariants("my", "custom", "variants")
}

If the plugin cannot find any variants by these names, it will first fallback to the defaults ("debug" and "main"), and then simply ignore the given subproject.

Failure conditions and filtering

By default, the plugin’s tasks will not fail a build upon detection of dependency issues; they simply print results to console and to disk. If you would prefer your build to fail if there are issues, you can configure the plugin as follows:

root build.gradle

dependencyAnalysis {
  issues {
    // Default for all issue types is "warn"
    // Can set behavior for all issue types
    onAny {
      fail() // or...
      warn() // or...
      ignore()
    }
    // Or configure behavior per-type
    onUnusedDependencies { ... }
    onUsedTransitiveDependencies { ... }
    onIncorrectConfiguration { ... }
  }
}

It is also possible to tell the plugin to filter out specific dependencies. Both the fail() and warn() except a String varargs or Iterable<String>. For example:

root build.gradle

dependencyAnalysis {
  issues {
    onUnusedDependencies {
      fail("org.jetbrains.kotlin:kotlin-stdlib-jdk7", "androidx.core:core-ktx")
    }
  }
}

Please note that the ignore() method takes no argument, as it already tells the plugin to ignore everything.

If your build fails, the plugin will print the reason why to console, along with the path to the report. Please see [Use cases](#use-cases), above, for help on understanding the report.

"Facade" dependencies

Since v0.41.0

A facade dependency is a family of dependencies that are meant to be consumed via a facade. For example, the org.jetbrains.kotlin:kotlin-stdlib-jdk8 dependencies transitively includes org.jetbrains.kotlin:kotlin-stdlib, making this pair of dependencies into a family. Users are typically expected to declare the facade (in this case the -jdk8 variant), and use the transitively included dependency (the un-decorated "core" variant) without having to declare it.

By default, the plugin will consider kotlin-stdlib- family of dependencies to be in such a family, and will not warn users about using the core kotlin-stdlib artifact without declaring it; nor will it warn about the kotlin-stdlib- variant being "unused" if a member of the family is used. This behavior is configurable.

If you want to add custom "facade" groups (by "group" we mean org.jetbrains.kotlin to continue the example), you can do the following:

root build.gradle

dependencyAnalysis {
  setFacadeGroups("com.some-group", "com.another-group")   // varargs; or
  setFacadeGroups(["com.some-group", "com.another-group"]) // iterable
}

Please note that, when explicitly setting the facade groups, this will unset the default Kotlin group. If you also want that, you must add it yourself.

If this facade behavior is considered undesirable, you may set an empty group as follows:

root build.gradle

dependencyAnalysis {
  setFacadeGroups()
}

"Ktx" dependencies

In Android, it is common to add dependencies like androidx.core:core-ktx and androidx.preference:preference-ktx. It is also apparently quite common for apps to not use the Kotlin extensions provided by these dependencies, but only the transitive dependencies included with these so-called "ktx" dependencies. When this (quite often) happens, the plugin will — correctly — report that the ktx dependency is unused, and some of its transitive dependencies are used, and the dependency graph should be updated accordingly. Android developers resist this advice, and since this resistance is fortified by the vast and growing ecosystem of these dependencies, along with documentation that uniformly recommends including them in apps, this plugin now provides a configuration option to "ignore ktx dependencies". That may be enabled as follows:

root build.gradle

dependencyAnalysis {
  issues {
    ignoreKtx(true) // default is false
  }
}

This will only ignore ktx dependencies if one of their transitives is actually used. If your app using neither of the direct nor any of its transitives, the plugin will still suggest removing that ktx dependency.

Controlling the projects on which the plugin is applied

On very large projects, the plugin’s default behavior of auto-applying itself to all subprojects can have major performance impacts. To mitigate this, the plugin can be configured so that it must be manually applied to each subproject of interest.

root build.gradle

dependencyAnalysis {
  autoApply(false) // default is true
}

Configuring level of console output

On larger builds, the plugin’s default behavior of printing the advice directly to the console can have negative performance ramifications (printing is slow). If you are comfortable reading the advice as json (printed to disk), you can reduce the "chattiness" like so:

root build.gradle

dependencyAnalysis {
  chatty(false) // default is true
}