I know that might only help you in the future, but why don't you just dump `mvn dependency:tree` into your build logs and maybe even attach it to the artifact somewhere in META-INF/maven or so? I am co-maintaining an OSS project which depends on another one using dependency version ranges. We do not want that and depend on fixed versions for our releases, so I always dump that output when upgrading from upstream, manually adjusting our own dependency versions for the upstream stuff we use.
Alternatively, you can look into: https://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html I have not tried, but read about it and remembered when reading your question. You can fine-tune the options for what you want replaced. You could run the goal, copy the resulting POM, then revert. A personal note: I am trying to keep my hands off version ranges. I am not sure the assumed flexibility is worth the trouble of using it and running into the same issues as you. It also potentially creates a huge matrix of possible dependency version combinations which might or might not play nice with each other. How can you ensure to run your tests on all of them? Sometimes, there is a bug which affects you in 2.5.3, but not in 2.5.2, and quickly fixed in 2.5.4. Maybe you did or did not notice that it even exists. Then suddenly, someone uses the buggy version, and the software does not work despite green tests. -- Alexander Kriegisch https://scrum-master.de Mark Derricutt schrieb am 14.04.2022 05:49 (GMT +07:00): > I don’t believe there currently is a way for this is native maven. > > We ended up writing a custom tool/mojo for resolution management using a > DSL like: > > repository https://repo1.maven.org/maven2/ as central; > > resolve highest org.antlr:antlr4-maven-plugin:[4.10,5.0.0) via central; > > locked org.antlr:antlr4-maven-plugin:4.10; > > > Which tracks the repositories to check, a range to resolve, and what was > resolved/locked ( also tracking deprecated/blacklisted dependencies ). > > These pom.deps files get attached as artifacts and can be subsequently > imported in downstream repos: > > repository https://nexus.az1.smxk8s.net/repository/maven-public-group; > > import groupId:artifact.bill-of-materials:3.3.150; > > locked org.antlr:antlr4-maven-plugin:4.10; > > >>From here, the actual pom.xml files are rewritten with > <version>[4.10]</version> references - locking the build to a specific, > locked range version ( for extra banality we also automatically add > <exclusions> on * to prevent transitive dependencies. > > This definitely has problems, but also have benefits and certainly made hot > fixes much easier to handle when we had different deployments staggered > into production between customer sites. > > -- > "Great artists are extremely selfish and arrogant things" — Steven Wilson, > Porcupine Tree > > > On 14/04/2022 at 6:25:47 AM, "Creager, Greg" <greg.crea...@hp.com.invalid> > wrote: > >> I am trying to reproduce a build that was done a week ago. Our maven pom >> files use range in many places ([1.0,1.1), when I go look at the pom of the >> published project, it just shows the range, not the actual version chosen: >> >> Published pom: >> <dependency> >> <groupId>com.hp.cp.dfe.shared</groupId> >> <artifactId>common-types</artifactId> >> <version>[1.0,1.1)</version> >> </dependency> >> >> >> How do I determine exact versions of dependencies used in a prior build? >> In Apache ivy the published ivy.xml shows the exact version chosen, I was >> expecting maven to have the same and I am assuming I just am not using the >> right util. >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
