The idea is simple - many (not all) projects are built using modules that
assign the same version to all artifacts. If we're using some of these
dependencies we generally (not always) want them to be the same version.
I don't think this is possible today but I could be mistaken.
*Current best practices*
For context it's common to see poms where all versions are listed as
properties, e.g.,
<jackson.version1.2.3</jackson.version>
and then the dependencies (ideally in the dependency management stanza) all
use
<version>${jackson.version}</version>
(ideally in a separate bom)
This makes it easy to update your dependencies - single point of truth -
but it doesn't necessarily apply to transient dependencies. This is
especially common if the transient dependency is resolved first since
(iirc) it will default to its own version and the our explicit
dependencies will use their own version.
I've seen this happen a lot. It's happening today with the maven dependency
plugin:
[INFO] org.apache.maven:maven-archiver:jar:3.6.2:compile -- module
maven.archiver (auto)
[INFO] org.apache.maven:maven-artifact:jar:3.6.3:provided -- module
maven.artifact (auto)
[INFO] org.apache.maven:maven-builder-support:jar:3.6.3:provided --
module maven.builder.support (auto)
[INFO] org.apache.maven:maven-compat:jar:3.6.3:test -- module
maven.compat (auto)
[INFO] org.apache.maven:maven-core:jar:3.6.3:provided -- module
maven.core (auto)
[INFO] org.apache.maven:maven-model-builder:jar:3.6.3:provided -- module
maven.model.builder (auto)
[INFO] org.apache.maven:maven-model:jar:3.6.3:provided -- module
maven.model (auto)
[INFO] org.apache.maven:maven-plugin-api:jar:3.6.3:provided -- module
maven.plugin.api (auto)
[INFO] org.apache.maven:maven-repository-metadata:jar:3.6.3:provided --
module maven.repository.metadata (auto)
[INFO] org.apache.maven:maven-resolver-provider:jar:3.6.3:provided --
module maven.resolver.provider (auto)
[INFO] org.apache.maven:maven-settings-builder:jar:3.6.3:provided --
module maven.settings.builder (auto)
[INFO] org.apache.maven:maven-settings:jar:3.6.3:provided -- module
maven.settings (auto)
*Possible solution #1*
The optimal solution would probably be extending the pom, probably in the
dependencyManagement stanza, that allows the developer to explicity specify
a default groupId -> version mapping. This value would be the default in
both dependencyManagement and dependencies. (Ditto with pluginManagement
and plugins)
This would support a definitive answer to the question of whether there
were any unexpected dependency versions. This would normally be a warning
but I can also see this being used to halt a build until it can be
investigated. There would also need to be a way to explicitly acknowledge
exceptions, e.g., any exception in the top-most pom is accepted but all
transient dependencies must use the expected version.
*Possible solution #2*
A second possibility is following the lead of the best practice mentioned
above. It's not as reliable since people may use different conventions
since the plugin has access to the raw pom it can look for any <x.version>
entries in the properties and then check whether that value is used in any
dependencies. If so, esp. if it happens more than once, then it can be
treated the same as above.
Bear Giles
