If you want to align versions, use dependency management + properties, this
will apply to transitive dependencies too.
Le jeu. 27 mars 2025 à 17:44, Bear Giles <bgi...@coyotesong.com> a écrit :
> 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
>
--
------------------------
Guillaume Nodet
