dependency-versions-check:check

Fail the build if a conflict is detected. Any conflict (direct and transitive) will cause a failure.

List only dependencies in conflict or all dependencies.

Use deep scan or regular scan. Deep scan looks at all dependencies in the dependency tree, while regular scan only looks one level deep into the direct dependencies.

Sets the default strategy to use to evaluate whether two dependency versions are compatible or not.

The default resolution strategy matches the Maven dependency resolution itself; any two dependencies that maven considers compatible will be accepted.

Fail the build only if a version conflict involves one or more direct dependencies. Direct dependency versions are controlled by the project itself so any conflict here can be fixed by changing the version in the project.
It is strongly recommended to review and fix these conflicts.

List only direct dependencies or all dependencies.

List of version checks that will be removed from the version check. This allows potential conflicts to be excluded.

<exclusions>
  <exclusion>
    <dependency>...</dependency>
    <expected>...</expected>
    <resolved>...</resolved>
  </exclusion>
</exclusions>

Each element consists of a dependency pattern [groupId]:[artifactId] that supports wildcards and an expected version (which is the version is expected by the artifact) and a resolved version (the version that the dependency resolution has chosen).

Run dependency resolution in parallel with multiple threads. Should only ever set to false if the plugin shows stability problems when resolving dependencies. Please file a bug in that case, too.

Include POM projects when running on a multi-module project. Dependency resolution on a pom project almost never makes sense as it does not actually build any artifacts.

List only managed dependencies or all dependencies.

Require all optional dependencies to exist and fail the build if any optional dependency can not resolved. This is almost never needed and actually causes problems for some projects that use large public dependencies from central that in turn pull in non-public dependencies as optional.

Silence all non-output and non-error messages.

List of resolvers to apply specific strategies to dependencies.

<resolvers>
  <resolver>
    <strategy>...<strategy>
    <includes>
      <include>...<include>
    <includes>
  <resolver>
<resolvers>

A resolver maps a specific strategy to a list of includes. The include syntax is [group-id]:[artifact-id] where each pattern segment supports full and partial wildcards (*).
The plugin includes some default strategies: apr, default, single-digit and two-digits-backward-compatible. Additional strategies can be defined and added to the plugin classpath.

Dependency resolution scope. Defaults to test. Valid choices are compile+runtime, compile, test and runtime.

Skip the plugin execution.

Fail the build if an artifact in system scope can not be resolved. Those are notoriously dependent on the local build environment and some outright fail (e.g. referencing the tools.jar, which no longer exists in a JDK8+ environment).
Setting this flag to true will fail the build if any system scoped artifact can not be resolved. This is almost never desired, except when building a project with a direct system scoped dependency.