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
, 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
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
, 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/<ht
--
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
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
itects 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 do
: 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 h
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
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
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
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
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
13 matches
Mail list logo
