Howdy, two very wrong conclusions here: 1- "artifacts in the same groupId have the same version" - nope. The fact they are in the same G does NOT have to mean they also share a "release lifecycle". 2- example of above is maven-archiver: it is NOT part of Maven "core", but is in this G by mistake (historically). The latest version (4) is in fact moved to org.apache.maven.shared G
To manage and align versions, as Guillaume mentioned: dependency management and properties. my 5 centa T On Thu, Mar 27, 2025 at 5:46 PM Bear Giles <[email protected]> wrote: > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
