RE: Determine Maven Dependencies after a build
Great link, thanks you so much From: Shipp, Scott Sent: Tuesday, April 19, 2022 8:55 AM To: Maven Users List Subject: Re: Determine Maven Dependencies after a build I also wanted to add that there is a reproducible builds guide at https://maven.apache.org/guides/mini/guide-reproducible-builds.html<https://maven.apache.org/guides/mini/guide-reproducible-builds.html> which also links to a wiki about the topic. There is a lot you can do to insure reproducible builds with Maven. From: Creager, Greg mailto:greg.crea...@hp.com.INVALID>> Date: Friday, April 15, 2022 at 8:10 AM To: Maven Users List mailto:users@maven.apache.org>> Subject: RE: Determine Maven Dependencies after a build External Email Is there a drawback to simply running resolve-ranges before official builds to ensure the pom has static versions? That seems like it would resolve having published poms with version ranges in production. mvn versions:resolve-ranges -DprocessParent=true From: Mark Derricutt mailto:m...@talios.com>> Sent: Wednesday, April 13, 2022 4:49 PM To: Maven Users List mailto:users@maven.apache.org>> Subject: Re: Determine Maven Dependencies after a build 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2Fdata=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3Dreserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2Fdata=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3Dreserved=0><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3Dreserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3Dreserved=0>><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2Fdata=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3Dreserved=0%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3Dreserved=0%3e<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2Fdata=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3Dreserved=0%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3Dreserved=0%3e>> 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frep
Re: Determine Maven Dependencies after a build
I also wanted to add that there is a reproducible builds guide at https://maven.apache.org/guides/mini/guide-reproducible-builds.html which also links to a wiki about the topic. There is a lot you can do to insure reproducible builds with Maven. From: Creager, Greg Date: Friday, April 15, 2022 at 8:10 AM To: Maven Users List Subject: RE: Determine Maven Dependencies after a build External Email Is there a drawback to simply running resolve-ranges before official builds to ensure the pom has static versions? That seems like it would resolve having published poms with version ranges in production. mvn versions:resolve-ranges -DprocessParent=true From: Mark Derricutt Sent: Wednesday, April 13, 2022 4:49 PM To: Maven Users List Subject: Re: Determine Maven Dependencies after a build 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2Fdata=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3Dreserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3Dreserved=0><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2Fdata=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3Dreserved=0%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3Dreserved=0%3e> 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-groupdata=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3Dreserved=0;<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-groupdata=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3Dreserved=0;><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-groupdata=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3Dreserved=0;%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-groupdata=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3Dreserved=0;%3e> 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 [4.10] references - locking the build to a specific, locked range version ( for extra banality we also automatically add on * to prevent transitive dependencies. This definitely has problems, but also have benefits and certainly made hot fixes mu
RE: Determine Maven Dependencies after a build
On 16/04/2022 at 3:09:09 AM, "Creager, Greg" wrote: > Is there a drawback to simply running resolve-ranges before official > builds to ensure the pom has static versions? That seems like it would > resolve having published poms with version ranges in production. > mvn versions:resolve-ranges -DprocessParent=true > On the surface that may seem like a good approach, but what we found along time ago, this led to: - The build you’re running on local dev machines, and ci servers, and on whatever machine does the release - may not actually be the same versions that were tested. - One concrete issue we saw early on what a spring related dependency that we had locked down, but that dependency itself had an open range dependency on spring with something like [2.0.0,] - when spring 3 was released, those dependencies got pulled into a build that then broke. This was on an associates project, but we had similar issues that tripped up runtime dependencies in our OSGi environment. - Rather than a giant multi-module project, we have multi-repos - so when it came to doing a hot fix of the distribution/packing, we’d take the bill of materials that was used in the version we’re replacing, and resolve ONLY a newer version of the sub-modules we’re replacing - for example: import company:company.distribution:111-ga1; allow unlocked /^.company:the-patched-artifact$/; Also on that patched artefact, we’d change that import to same released version and resolve the used dependencies specifically to what’s being replaced in production. It’s a small amount of ceremony but it has served to minimise the surface area of change for retesting. The downside of forcing [] versions and no transitives, does mean occasionally we end up with a large amount of re-releasing modules that only contain dependency version updates, often that’s only needed if major versions have changed, or minor versions of API specific artifacts. One thing I have been considering adding to this was also recording the checksums of the artifacts resolved, to help mitigate any potential side chain attacks. -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree
RE: Determine Maven Dependencies after a build
Is there a drawback to simply running resolve-ranges before official builds to ensure the pom has static versions? That seems like it would resolve having published poms with version ranges in production. mvn versions:resolve-ranges -DprocessParent=true From: Mark Derricutt Sent: Wednesday, April 13, 2022 4:49 PM To: Maven Users List Subject: Re: Determine Maven Dependencies after a build 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/<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;<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 [4.10] references - locking the build to a specific, locked range version ( for extra banality we also automatically add 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" mailto: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: > > com.hp.cp.dfe.shared > common-types > [1.0,1.1) > > > > 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. >
Re: Determine Maven Dependencies after a build
Hello, I think you can’t publish ranges to central, but yes if a dependency has a range each built will resolve the Version new, and unless there is a mother dependency fixing the version you get the latest one in that range from your repo. As others said, just don’t use ranges. Gruss Bernd -- http://bernd.eckenfels.net Von: Creager, Greg Gesendet: Thursday, April 14, 2022 5:37:21 PM An: Maven Users List Betreff: RE: Determine Maven Dependencies after a build Another question, if the published pom has a range: Published pom: com.hp.cp.dfe.shared common-types [1.0,1.1) Does that mean when another maven build that depends on this will select the latest available common-types in that range, not the one that was used for that build? (my hunch is yes, constant moving target) -Original Message- From: Nils Breunese Sent: Thursday, April 14, 2022 2:01 AM To: Maven Users List Subject: Re: Determine Maven Dependencies after a build Alexander Kriegisch wrote: > 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. I would indeed also recommend to not use version ranges, and using a tool like Dependabot or Renovate to keep your dependencies up-to-date. Nils. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Determine Maven Dependencies after a build
Another question, if the published pom has a range: Published pom: com.hp.cp.dfe.shared common-types [1.0,1.1) Does that mean when another maven build that depends on this will select the latest available common-types in that range, not the one that was used for that build? (my hunch is yes, constant moving target) -Original Message- From: Nils Breunese Sent: Thursday, April 14, 2022 2:01 AM To: Maven Users List Subject: Re: Determine Maven Dependencies after a build Alexander Kriegisch wrote: > 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. I would indeed also recommend to not use version ranges, and using a tool like Dependabot or Renovate to keep your dependencies up-to-date. Nils. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Determine Maven Dependencies after a build
I suspect you could use dependency plugin and copy dependencies goal to pin them for now and store the produced archive somewhere for now. On Thu, Apr 14, 2022, 17:24 Creager, Greg wrote: > Thanks for all the quick responses, greatly appreciate it. I’ll have to > work with our architects and see if I can steer them away from this, build > reproducibility is highest priority. > > Thanks again > > From: Mark Derricutt > Sent: Wednesday, April 13, 2022 4:49 PM > To: Maven Users List > Subject: Re: Determine Maven Dependencies after a build > > 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/<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;< > 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 > [4.10] references - locking the build to a specific, > locked range version ( for extra banality we also automatically add > 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" <mailto: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: > > > > com.hp.cp.dfe.shared > > common-types > > [1.0,1.1) > > > > > > > > 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. > > >
RE: Determine Maven Dependencies after a build
Thanks for all the quick responses, greatly appreciate it. I’ll have to work with our architects and see if I can steer them away from this, build reproducibility is highest priority. Thanks again From: Mark Derricutt Sent: Wednesday, April 13, 2022 4:49 PM To: Maven Users List Subject: Re: Determine Maven Dependencies after a build 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/<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;<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 [4.10] references - locking the build to a specific, locked range version ( for extra banality we also automatically add 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" mailto: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: > > com.hp.cp.dfe.shared > common-types > [1.0,1.1) > > > > 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. >
Re: Determine Maven Dependencies after a build
Alexander Kriegisch wrote: > 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. I would indeed also recommend to not use version ranges, and using a tool like Dependabot or Renovate to keep your dependencies up-to-date. Nils. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Determine Maven Dependencies after a build
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 > [4.10] references - locking the build to a specific, > locked range version ( for extra banality we also automatically add > 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" > 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: >> >> com.hp.cp.dfe.shared >> common-types >> [1.0,1.1) >> >> >> >> 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
Re: Determine Maven Dependencies after a build
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 [4.10] references - locking the build to a specific, locked range version ( for extra banality we also automatically add 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" 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: > > com.hp.cp.dfe.shared > common-types > [1.0,1.1) > > > > 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. >
Re: Determine Maven Dependencies after a build
I don't think you can. The only way would be to use metadata from those GAV and see when it was released/deployed. Of if your don't use use " -ntp,--no-transfer-progress" AND a new workspace per build AND have that log, then you would see what if downloads. Or you use a local/company repository manager like nexus and still have the access logs. Of your creating a artifact which includes it's dependencies, then either check the dependency checksum or jar metadata But gut tells me you can't. John On Wed, 13 Apr 2022 at 19:26, Creager, Greg 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: > >com.hp.cp.dfe.shared >common-types >[1.0,1.1) > > > > 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. >
Determine Maven Dependencies after a build
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: com.hp.cp.dfe.shared common-types [1.0,1.1) 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.
