This is an automated email from the ASF dual-hosted git repository. slachiewicz pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/maven-dependency-plugin.git
commit 2ea007071736ff50df0e375cd43782dcd1c66bb4 Author: Sylwester Lachiewicz <[email protected]> AuthorDate: Thu Oct 29 22:23:38 2026 +0000 Move the bytecode analysis section after the lifecycle example --- .../exclude-dependencies-from-dependency-analysis.md.vm | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/site/markdown/examples/exclude-dependencies-from-dependency-analysis.md.vm b/src/site/markdown/examples/exclude-dependencies-from-dependency-analysis.md.vm index 835d0e74..57155b29 100644 --- a/src/site/markdown/examples/exclude-dependencies-from-dependency-analysis.md.vm +++ b/src/site/markdown/examples/exclude-dependencies-from-dependency-analysis.md.vm @@ -85,6 +85,14 @@ Each ignore pattern has the form `[groupId]:[artifactId]:[type]:[version]:[scope The four lists can also be set on the command line, as comma-separated patterns, through the `mdep.analyze.ignoredDependencies`, `mdep.analyze.ignoredUsedUndeclaredDependencies`, `mdep.analyze.ignoredUnusedDeclaredDependencies` and `mdep.analyze.ignoredNonTestScopedDependencies` properties. The `dependency:analyze-dep-mgt` goal accepts the same patterns in its own `ignoredDependencies` parameter and skips the matching artifacts. +Note that the `dependency:analyze-only` goal is used in preference to `dependency:analyze` since it doesn't force a further compilation of the project, but uses the compiled classes produced from the earlier `test-compile` phase in the lifecycle. + +The project's dependencies will then be automatically analyzed during the `verify` lifecycle phase, which can be executed explicitly as follows: + +```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: @@ -101,11 +109,3 @@ Keep these dependencies declared, and tell the analysis about them in one of the * `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. - -Note that the `dependency:analyze-only` goal is used in preference to `dependency:analyze` since it doesn't force a further compilation of the project, but uses the compiled classes produced from the earlier `test-compile` phase in the lifecycle. - -The project's dependencies will then be automatically analyzed during the `verify` lifecycle phase, which can be executed explicitly as follows: - -```shell -mvn verify -```
