Le mardi 24 septembre 2019, 02:28:15 CEST Mark Derricutt a écrit : > Tomo Suzuki wrote on 23/09/19 3:56 PM: > > Does your approach use such file to record library versions? > > I don't know about what Hervé is doing, I added an "out of scope" paragraph: managing version ranges in a stable way is not in the scope https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318#Reproducible/VerifiableBuilds-Outofscope
> but internally we have a tool I > wrote for handling this, we have a pom.deps file that looks like: nice separation of concerns: stable versions chosen vs updates controlled with ranges with such an approach, version ranges could become something I love :) Regards, Hervé > > repository http://nexus.XXXXXX as public; > > import smx3:smx3.upstream.bill-of-materials:1.1.22; > > resolve highest org.jetbrains:annotations:[16.0.3,17.0.0) via public; > resolve highest > org.apache.maven.plugins:maven-jar-plugin:[3.1.2,4.0.0) via public; > resolve highest org.apache.cxf:cxf-codegen-plugin:[3.3.3,4.0.0) via > public; > > which when we resolve, will find the highest, snapshot, or lowest > version in a given range - also allowing filtering out annoying things > like beta/alpha/CR from central, and rewriting the pom.xml's. > > Our tooling also has an 'import' option shown above that lets us > standardize the versions we resolving, and breaking it up - so we have > 'upstream.bill-of-materials' and 'upstream.testing.bill-of-materials`. > > As part of this we also add in <exclusions> to ban all transitive build > deps, and [] range all version references. > > I keep meaning to push for open sourcing it, but just haven't had the time. > > Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
