Skip to content

Document dependencies that dependency analysis cannot see #1778

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
slachiewicz merged 2 commits into from
Oct 29, 2026
Merged

Document dependencies that dependency analysis cannot see #1778

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b015682
Document dependencies that bytecode analysis cannot see
slachiewicz Oct 29, 2026
c9de287
Move the bytecode analysis section after the lifecycle example
slachiewicz Oct 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions src/site/markdown/examples/exclude-dependencies-from-dependency-analysis.md.vm
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -92,3 +92,20 @@ The project's dependencies will then be automatically analyzed during the `verif
```shell
mvn verify
```

## Dependencies that bytecode analysis cannot see

The analysis reads class references from the compiled classes only. A dependency that the code reaches in another way is reported as "declared but unused", even though removing it breaks the build or the application at runtime. Typical cases are:

* `ServiceLoader` (SPI) providers, such as a JDBC driver, a logging backend or a transport implementation, that are found through `META-INF/services`.
* Sisu and Plexus components, which are found through `META-INF/sisu` or `META-INF/plexus/components.xml`.
* Test engines and test infrastructure, such as `junit-jupiter-engine` or a Surefire provider, that the test runner loads by name.
* Runtime-only libraries, such as a driver that is selected by a configuration value.

Keep these dependencies declared, and tell the analysis about them in one of the following ways:

* `usedDependencies` forces a dependency to count as used: `<usedDependencies><usedDependency>org.postgresql:postgresql</usedDependency></usedDependencies>`.
* `ignoredUnusedDeclaredDependencies` hides the "declared but unused" warning for the matching dependencies. The pattern can select by scope, for example `org.acme:::*:runtime`.
* `ignoreUnusedRuntime` ignores all runtime-scoped dependencies for the "declared but unused" check, and `ignoreNonCompile` ignores all runtime, provided, test and system-scoped dependencies.

The reverse case is a test that uses a class from a provided or runtime dependency that reaches the project only transitively. The analysis reports it as "used undeclared", and the dependency belongs in the project's POM in `test` scope. The `ignoredNonTestScopedDependencies` list is for the different case where a `compile`-scoped dependency is used by tests only and is deliberately kept in that scope.
Loading