Hello, libraries that publish many artifacts that are meant to be used all with the same version publish a BOM (Bill of Materials) and then you import it in the dependencyManagement section
Like this: https://github.com/FasterXML/jackson-bom Enrico Il giorno ven 28 mar 2025 alle ore 20:30 Tamás Cservenák < ta...@cservenak.net> ha scritto: > 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 <bgi...@coyotesong.com> 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: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
