dependency-analysis only looks at modules with the right plugin applied, and the rest report nothing

A module the plugin does not analyse produces no output and no warning

The plugin's scope is stated as a restriction, and it is the most important sentence on the page. It only analyses modules with specific plugins applied.

Four plugin ids cover Android modules, including an application, a library, a test module and the Android target of Kotlin's multiplatform plugin. Two cover the JVM: the Java library plugin and the Kotlin JVM plugin. Two more cover multiplatform modules, but only for the two named targets, the JVM one and the Android library one. So a multiplatform module with other targets is analysed only where those targets exist.

The catch is in the last group. Three more plugins are supported, but only when they also have an application plugin applied, or, for Groovy and Scala, the Java library plugin. A module with the plain Java plugin on its own is not in the list at all.

So the plugin's silence is not evidence of health. A module the plugin skipped produces no findings, no warning that it was skipped, and a clean-looking report. On a mixed repository that is the difference between a clean build and an unexamined module, and nothing in the output distinguishes the two.

The documented quick start ends in a failed build

The quick start is one command.

./gradlew buildHealth

And then the page shows what you will probably see, which is a task failure:

> Task :buildHealth FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':buildHealth'.
> There were dependency violations. See report at file:///path/to/project/build/reports/dependency-analysis/build-health-report.txt

That is deliberate. The plugin is configured to fail on any issue, and the example configuration sets that severity for every issue at once. So a first run on an existing project fails, by design, and the output names a report file rather than a diagnosis.

The report itself is a text file under the build directory. If you want it in the console as well, the page adds a reporting option to the plugin's own configuration block. That is a second configuration block to learn, and it is the difference between seeing a failing task and reading why.

The severity is not a fixed default of the plugin either. It is a property of how the user configures it, which means two teams on the same plugin can have opposite build outcomes.

Severity rules depend on a classification held in a list of four plugin ids

The plugin draws a line between libraries and applications, and the line is drawn by plugin id rather than by how a module behaves.

Libraries have an API. Applications do not. In practical terms, the page says application modules should not carry API-like dependencies, because an application has nothing to expose.

A module is treated as an application if it applies one of four plugins: the application plugin, a server-side Groovy build plugin, a Java image build plugin, or the Spring Boot plugin. Everything else is a library.

That is a coarse classifier doing a lot of work. A service built on a web framework other than Spring Boot, or deployed with a tool other than the Java image builder, is a library as far as this plugin is concerned, so it gets the library rules and the library findings. The same codebase can be judged correctly or incorrectly depending on which build plugin somebody happened to pick.

It also means the plugin can recommend removing a dependency that a library legitimately needs to expose, in a module that only looks like an application because of the plugin it applies.

The property named for inclusion ships an example that excludes

Partial analysis is the documented answer to a very large project, and the mechanism is a Gradle property whose name and example point in opposite directions.

The property is named for the projects to include. Its documented example excludes:

# Include all projects except those whose path begins with `:prefix`
dependency.analysis.project.includes=^((?!:prefix)).*$

The value is evaluated as a regular expression, and the example uses a negative lookahead to match everything whose path does not begin with a given prefix. So the comment is accurate about what the value does and the property name is accurate about what it controls, and a reader who writes their own regular expression has to work out which of the two they are expressing.

Two other routes to partial analysis are offered before it. One is a task that analyses a single project. The other, recommended for very large projects, is to apply the other plugin id selectively instead of the one used above, which means the global configuration and the per-project configuration are different surfaces and only one of them is the short path the quick start shows.

The build badge and the install instructions both point at a different repository

The page delegates. It says that for detailed instructions, see a wiki, and the wiki belongs to a sibling repository rather than to this one.

The build badge does the same thing more quietly. Its image comes from this repository's test workflow, so the status it shows is this repository's status, and its link goes to the sibling repository's workflow page. Clicking a green build badge takes you somewhere else.

The version badges are also split. The release badge reads its metadata from one repository host and the snapshot badge from another, which is the modern arrangement and not a problem, though it does mean the two numbers on the page come from two different services.

Then there is the requirement the page marks as important, in capitals. If a project uses Kotlin or Android, those plugins must also be loaded in the settings script classloader, or a parent of it. That is a classloader ordering constraint rather than a version constraint, and it changes what the plugin can see. A project that gets it wrong does not get a clear error; it gets fewer findings.

The repository instructions still describe a two point series

There is a section on which repositories to declare, and it opens with a version statement.

It says that from version two point nineteen for releases, and two point eighteen point one snapshot for snapshots, the plugin is published through a new repository host rather than the old one. Then it gives the configuration block: the central repository for releases, the snapshot repository on the same host, and the plugin portal, with a comment explaining that once you use the plugin management block you should add the portal explicitly unless you never want that repository.

The version numbers in that sentence belong to the two point series. The tags are in the three point series, and the release badge reads a three point version. So the repository configuration is right and the sentence describing when it became right is two series out of date.

The comment about the plugin portal is the practical part. A project that adopts this configuration gets three repositories where it had none, and one of them is a fallback that the comment tells you to think about twice.

A patch release was published before the minor release it followed

Three recent tags are visible and they are not in the order they shipped.

A minor release, three point nineteen point zero, was published at eighteen hundred on one date. A patch release, three point nineteen point one, was published at fourteen minutes past midnight on the same date, roughly eighteen hours earlier. A second patch, three point nineteen point two, came about three weeks after that.

So the release list is not chronological, and the version numbers are not in the order the tags were cut. A build that pins a version and reads the release list to find out what is current will pick the wrong one.

The last push to the branch is dated the day before the current date, and the newest tag is about a fortnight older. So development is ahead of the last release, which is normal for a plugin, and it means the changes on the branch are not in any published version.

Five build modules at the root, one of them named shadowed

A Gradle plugin is one artifact, and this repository is not one module.

At the root there are five directories that are not the plugin itself. One is the plugin's public API. One holds the build logic, which is the modern way to share convention plugins. One is a test kit, which is how the plugin tests itself. One supports the project graph feature. And one is named for a concept rather than a purpose: a directory called shadowed, with nothing on the page explaining what it contains or why it is separate.

Then there is the variant artifacts directory, which is presumably about the per-variant outputs the dominator tree feature needs, and is also unexplained.

The rest of the root is the standard set plus a few choices. The wrapper is committed, as it must be. The changelog, a code of conduct, a licence file, a release guide, a publishing guide and a contributing guide, with three of those in AsciiDoc and the rest not. A JavaScript-like configuration file for dependency update automation, written in a superset of JSON. And a directory of editor project files committed to the repository, next to a cross-platform editor configuration file.

The first paragraph of the page, for what it is worth, is a pitch for consulting work, with a link to the author's organisation. That is above the feature list, which makes it the first thing a reader sees.

Editorial conclusion

The Dependency Analysis Gradle Plugin fits a Java, Kotlin, Groovy or Scala project on Gradle that wants a build that fails on a dependency it does not use, and it fits an Android or multiplatform project where the plugin ids are known and stable. Before turning it on, check four things. Confirm every module you want analysed has one of the listed plugin ids, because a module without one is silent rather than clean. Confirm each module is classified the way you intend, since the application and library rules are different and the classification is a fixed list of four plugin ids. Read the project path property before copying the example, because the property is named for inclusion and the example given implements exclusion. And check the version line in the repository instructions, which still refers to a two point series while the tags are three point.

Frequently asked questions

Official sources

1. autonomousapps/dependency-analysis-gradle-plugin on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases