Skip to content

Home

Jump to bottom
Tony Robalik edited this page Sep 15, 2021 · 8 revisions

Detailed guidance on how to use, and get the most out of, the Dependency Analysis Plugin.

Use cases

  1. You’re a library author and want to correctly declare your dependencies as api vs implementation so that users can easily consume your library.

  2. You maintain a project with a lot of dependencies and want to have control over and understanding of them. You want to insulate yourself from libraries changing their transitive dependencies in a way that would break your project.

  3. You maintain a very large project with a huge number of dependencies and it’s basically impossible to know what you actually use anymore, particularly as your team grows in size. You also want to break inter-project dependencies to enable more parallel compilation.

Advice

The plugin enables these use-cases through the concept of "advice". When you execute the buildHealth task, it analyzes your entire project, including all variants for Android projects, and does two things:

  1. Prints that advice to the console in an easy-to-read format.

  2. Prints that advice to disk as JSON for advanced users who want to automate post-processing the results.

The advice comes in the following flavors:

Dependency-related advice

  1. Unused dependencies which should be removed.

  2. Declared dependencies which are on the wrong configuration (api vs implementation vs compileOnly). This is variant-aware, so it might tell you to use debugImplementation, for example.

  3. Transitively used dependencies which ought to be declared directly, and on which configuration.

  4. Dependencies which could be declared on the compileOnly configuration, as they’re not required at runtime.

  5. Annotation processors which could be removed as unused.

Plugin-related advice

  1. Plugins that are applied but which can be removed. (currently we support kapt, java-library, and kotlin-jvm for redundancy-checking)

Output

As mentioned, the advice is printed to console in a narrative form, and also written to disk as JSON. The JSON output has several components (see the com.autonomousapps.advice.Advice model class):

  1. Dependency (identifier, resolved version, and declared configuration, if any)

  2. "fromConfiguration", which is the configuration on which the dependency is currently declared. Typically "api" or "implementation". If this field is not present, that means it is null and the dependency is transitive. It should be declared directly.

  3. "toConfiguration", which is the configuration on which the dependency should be declared. If this field is not present, that means it is null and the dependency should be removed.

Additionally, the Advice class includes

  1. usedTransitiveDependencies: Set<Dependency> for transitive dependencies that are used.

  2. parents: Set<Dependency> for unused dependencies that contribute this transitive dependency.

Clone this wiki locally