Customizing plugin behavior

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

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 {
    // configure for all projects
    all {
      // set behavior for all issue types
      onAny {
        severity(<'fail'|'warn'|'ignore'>) // default is 'warn'
        exclude('an:external-dep', 'another:external-dep', ':a:project-dep')
      }
      // or configure per-type
      onUnusedDependencies { ... }
      onUsedTransitiveDependencies { ... }
      onIncorrectConfiguration { ... }
      onCompileOnly { ... }
      onRuntimeOnly { ... }
      onUnusedAnnotationProcessors { ... }
      onRedundantPlugins { ... }
    }
    // and/or ignore the analysis for a complete source set (JVM projects)
    ignoreSourceSet('testFixtures', 'anotherSourceSet')
    ignoreSourceSet('unknown') // no effect
    // or configure per project
    project(':lib') {
      ...
    }
  }
}

Or if you prefer, you can configure this in the subproject’s build script directly (instead of using project(':some-project') {}

subproject some-project/build.gradle

dependencyAnalysis {
  issues {
    onAny {
      severity(<'fail'|'warn'|'ignore'>)
      exclude('an:external-dep', 'another:external-dep', ':a:project-dep')
    }
    onUnusedDependencies { ... }
    onUsedTransitiveDependencies { ... }
    onIncorrectConfiguration { ... }
    onCompileOnly { ... }
    onRuntimeOnly { ... }
    onUnusedAnnotationProcessors { ... }
    onRedundantPlugins { ... }
  }
}

If your build fails, the plugin will print the reason why to console, along with the path to the report. Please see Use cases, above, for help on understanding the report.

Logical dependency groups, aka dependency "bundles"

Since v0.47.0

A logical dependency or, to use the language of the DSL, a dependency "bundle", is a family of related dependencies that are meant to be consumed as a group, or logical whole, even though they are published as independent artifacts. For example, the org.jetbrains.kotlin:kotlin-stdlib-jdk8 dependency transitively includes org.jetbrains.kotlin:kotlin-stdlib, making this pair of dependencies into a a single logical whole. In this example, users are typically expected to declare the -jdk8 variant, and use the transitively included dependency (the un-decorated "core" variant) without having to declare it.

If you want to treat the Kotlin stdlib group as a dependency bundle, you can do the following:

root build.gradle

dependencyAnalysis {
  structure {
    bundle("kotlin-stdlib") {
      includeGroup("org.jetbrains.kotlin")
    }
  }
}

The name you specify for your bundle is arbitrary, but must be unique. See the javadoc on DependenciesHandler for more examples.

"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 {
  structure {
    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.

gradle.properties

# default is true
dependency.analysis.autoapply=false

ABI Filtering

See the dedicated page.