You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Creager, Greg" <gr...@hp.com.INVALID> on 2022/04/13 18:25:47 UTC
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:
<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.
RE: Determine Maven Dependencies after a build
Posted by "Creager, Greg" <gr...@hp.com.INVALID>.
Great link, thanks you so much
From: Shipp, Scott <ss...@ebay.com.INVALID>
Sent: Tuesday, April 19, 2022 8:55 AM
To: Maven Users List <us...@maven.apache.org>
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 <gr...@hp.com.INVALID>>
Date: Friday, April 15, 2022 at 8:10 AM
To: Maven Users List <us...@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 <ma...@talios.com>>
Sent: Wednesday, April 13, 2022 4:49 PM
To: Maven Users List <us...@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%2F&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2F&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3D&reserved=0><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3D&reserved=0>><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2F&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3D&reserved=0%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3D&reserved=0%3e<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2F&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3D&reserved=0%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3D&reserved=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-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=0;<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=0;><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=0;<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=0;>><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=0;%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=0;%3e<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=0;%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=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
<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" <gr...@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.
>
Re: Determine Maven Dependencies after a build
Posted by "Shipp, Scott" <ss...@ebay.com.INVALID>.
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 <gr...@hp.com.INVALID>
Date: Friday, April 15, 2022 at 8:10 AM
To: Maven Users List <us...@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 <ma...@talios.com>
Sent: Wednesday, April 13, 2022 4:49 PM
To: Maven Users List <us...@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%2F&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3D&reserved=0><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2%2F&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3XJIvZ9N5riGnqc0FZnFDU15c7gGODNp2AunJMNjx8g%3D&reserved=0%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.org%2Fmaven2&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ovkq%2BPgEPdZAULpXGSrFylbHql%2BmgCMydB8xidPMNn0%3D&reserved=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-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=0;<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=0;><https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=0;%3chttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnexus.az1.smxk8s.net%2Frepository%2Fmaven-public-group&data=04%7C01%7Csshipp%40ebay.com%7Cec7d60c7f926425c3e7508da1ef20dcb%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637856322352812697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GjTzWusSf4c8lJ74qMtCL4VQ2KzamM56t5AwfsbBLSg%3D&reserved=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
<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" <gr...@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.
>
RE: Determine Maven Dependencies after a build
Posted by Mark Derricutt <ma...@talios.com>.
On 16/04/2022 at 3:09:09 AM, "Creager, Greg" <gr...@hp.com.invalid>
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
Posted by "Creager, Greg" <gr...@hp.com.INVALID>.
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 <ma...@talios.com>
Sent: Wednesday, April 13, 2022 4:49 PM
To: Maven Users List <us...@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://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
<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" <gr...@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.
>
Re: Determine Maven Dependencies after a build
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
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 <gr...@hp.com.INVALID>
Gesendet: Thursday, April 14, 2022 5:37:21 PM
An: Maven Users List <us...@maven.apache.org>
Betreff: RE: Determine Maven Dependencies after a build
Another question, if the published pom has a range:
Published pom:
<dependency>
<groupId>com.hp.cp.dfe.shared</groupId>
<artifactId>common-types</artifactId>
<version>[1.0,1.1)</version> </dependency>
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 <ni...@breun.nl>
Sent: Thursday, April 14, 2022 2:01 AM
To: Maven Users List <us...@maven.apache.org>
Subject: Re: Determine Maven Dependencies after a build
Alexander Kriegisch <al...@kriegisch.name> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Determine Maven Dependencies after a build
Posted by "Creager, Greg" <gr...@hp.com.INVALID>.
Another question, if the published pom has a range:
Published pom:
<dependency>
<groupId>com.hp.cp.dfe.shared</groupId>
<artifactId>common-types</artifactId>
<version>[1.0,1.1)</version> </dependency>
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 <ni...@breun.nl>
Sent: Thursday, April 14, 2022 2:01 AM
To: Maven Users List <us...@maven.apache.org>
Subject: Re: Determine Maven Dependencies after a build
Alexander Kriegisch <al...@kriegisch.name> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Determine Maven Dependencies after a build
Posted by Nils Breunese <ni...@breun.nl>.
Alexander Kriegisch <al...@kriegisch.name> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Determine Maven Dependencies after a build
Posted by Alexander Kriegisch <al...@kriegisch.name>.
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" <gr...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Determine Maven Dependencies after a build
Posted by Mantas Gridinas <mg...@gmail.com>.
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 <gr...@hp.com.invalid>
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 <ma...@talios.com>
> Sent: Wednesday, April 13, 2022 4:49 PM
> To: Maven Users List <us...@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://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
> <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.creager@hp.com.invalid
> <ma...@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.
> >
>
RE: Determine Maven Dependencies after a build
Posted by "Creager, Greg" <gr...@hp.com.INVALID>.
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 <ma...@talios.com>
Sent: Wednesday, April 13, 2022 4:49 PM
To: Maven Users List <us...@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://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
<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" <gr...@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.
>
Re: Determine Maven Dependencies after a build
Posted by Mark Derricutt <ma...@talios.com>.
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" <gr...@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.
>
Re: Determine Maven Dependencies after a build
Posted by John Patrick <nh...@gmail.com>.
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 <gr...@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.
>