Re: maven-site job stuck on jenkins

Thank you, Hervé! Most appreciated. -Chris > On Sep 29, 2019, at 4:06 PM, Hervé BOUTEMY wrote: > > thank you Chris for the warning: fixed > (deleted this stale branch for a commit that was merged to master, but the > cleanup was not done, sorry...) > > Regards, > > Hervé > > Le dimanche

Re: maven-site job stuck on jenkins

thank you Chris for the warning: fixed (deleted this stale branch for a commit that was merged to master, but the cleanup was not done, sorry...) Regards, Hervé Le dimanche 29 septembre 2019, 23:29:55 CEST Chris Lambertus a écrit : > Hi Maven folks, > > The following build >

Re: [DISCUSS] configuration for Reproducible Builds

Le dimanche 29 septembre 2019, 21:31:58 CEST Emmanuel Bourg a écrit : > Le 29/09/2019 à 20:46, Hervé BOUTEMY a écrit : > > This is exactly how I see Reproducible Builds for the future: > > - select versions of plugins that bring reproducible output > > - either inherit or define a local timestamp

maven-site job stuck on jenkins

Hi Maven folks, The following build https://builds.apache.org/job/maven-box/job/maven-site/job/MNG-6432/ has been hung for some time due to the fact that it is using the incorrect label for the website builder node. The

Re: [DISCUSS] configuration for Reproducible Builds

While default stays not reproducible (keep in mind we enrich with dated timestamp or build user metadata in jar quite commonly and i dont think we want to sed/drop it) and reproducible mode gets an explicit flag in plugins it sounds very promishing to me, in particular for containers case. Le

Dependency upgrades & refactors

Hi, I was looking at the versions of things that maven-compiler-plugin depends on and raised a few PRs to bring things up to date: [MCOMPILER-377] Upgrade plexus-java from 0.9.10 to 1.0.3 https://github.com/apache/maven-compiler-plugin/pull/23 [MCOMPILER-389] Upgrade plexus-compiler-javac to

Re: [DISCUSS] configuration for Reproducible Builds

Le 29/09/2019 à 20:46, Hervé BOUTEMY a écrit : > This is exactly how I see Reproducible Builds for the future: > - select versions of plugins that bring reproducible output > - either inherit or define a local timestamp > > et voilà, it's so easy (once plugins support)... How do you plan to

Re: [DISCUSS] configuration for Reproducible Builds

Let's not talk about technologies but talk about the use case because the use case will uncover the purpose what target is in the background of this request. Romain, an therefore i was not firstly talking about concret SCM, but Harald, and it means the SCM can be one of the implementations -

Re: [DISCUSS] configuration for Reproducible Builds

Hunter wrote: What if that timestamp was based upon the scm's last commit timestamp > instead of the time of the build? > Folks: remember that Subversion works differently to Git. With subversion there's no hash, just an integer that goes up constantly for everything in the larger repo. Your

Re: [DISCUSS] configuration for Reproducible Builds

perhaps I should basically show how Reproducible Builds was configured in the PoC: 1. in apache-parent: https://github.com/apache/maven-apache-parent/commit/d379a72d07173c500be65fd6e549da1fedb46b5f It's about 3 packaging plugins that have a version supporting Reproducible Builds and one

Re: [DISCUSS] configuration for Reproducible Builds

scm does not work cause one common use case is to rebuild from source the same artifacts (debian rebuild from source AFAIK, even java apps) since scm can be "proxied", copied etc then the source can differ and therefore commits can be differents but the content can be the same this is why jib uses

Re: [DISCUSS] configuration for Reproducible Builds

yes Hunter, exactly this was one possibility. The names of the property can be just like in the HTTP Headers: Last-Modified If-Modified-Since -> maybe here can be also the commit hash, not only time in millis/UTC ETag and every module may have different value ;-) then. and then the SCM... has to

Re: [DISCUSS] configuration for Reproducible Builds

What if that timestamp was based upon the scm's last commit timestamp instead of the time of the build? Hunter On Sunday, September 29, 2019, 10:25:41 AM PDT, Tibor Digana wrote: Can somebody explain a realistic USE CASE when you trigger two consequent builds (with no changes in

Re: [DISCUSS] configuration for Reproducible Builds

Can somebody explain a realistic USE CASE when you trigger two consequent builds (with no changes in sources) and that you expect identical MD5 of the build artifacts (JAR)? This can be achieved only when the "timeStamp" in properties is fixed unmodified in POM. Does it make sense to call it

Re: [DISCUSS] configuration for Reproducible Builds

Hi all, Wonder if it can't "just" (this is not a small task but in terms of design it is small ;)) be a flag on higher level archiver plugins (maven-jar-plugin being the first one we'll all have in mind). I take as a reference jib here which takes into account a creation time for that case (

Re: [DISCUSS] configuration for Reproducible Builds

Le dimanche 29 septembre 2019, 12:29:47 CEST Karl Heinz Marbaise a écrit : > Hi Hervé, > > On 29.09.19 11:19, Hervé BOUTEMY wrote: > > regarding the property name, I had an idea: > > > > why not do like we already did for ${project.build.sourceEncoding}, ie. > > mimic a future element in

Re: [DISCUSS] configuration for Reproducible Builds

Le dimanche 29 septembre 2019, 16:31:35 CEST Robert Scholte a écrit : > On Sun, 29 Sep 2019 12:41:17 +0200, Enrico Olivelli > > wrote: > > Il dom 29 set 2019, 12:16 Robert Scholte ha > > > > scritto: > >> I would think that all project.* properties represent the pom.xml and > >> are > >>

Re: [DISCUSS] configuration for Reproducible Builds

Le dimanche 29 septembre 2019, 12:41:17 CEST Enrico Olivelli a écrit : > Il dom 29 set 2019, 12:16 Robert Scholte ha scritto: > > I would think that all project.* properties represent the pom.xml and are > > immutable. To be more precise: the same pom.xml should effectively stay > > the same with

Re: [DISCUSS] configuration for Reproducible Builds

Le dimanche 29 septembre 2019, 12:16:48 CEST Robert Scholte a écrit : > I would think that all project.* properties represent the pom.xml and are > immutable. To be more precise: the same pom.xml should effectively stay > the same with every build. +1 > Instead this seems more related the

Re: [DISCUSS] configuration for Reproducible Builds

Le dimanche 29 septembre 2019, 16:54:04 CEST Emmanuel Bourg a écrit : > Le 28/09/2019 à 17:55, Hervé BOUTEMY a écrit : > > Putting that parameter as a pom property with a well known name and value > > format permits to share the configuration between every packaging plugin. > > This also has the

Re: [DISCUSS] configuration for Reproducible Builds

Le 28/09/2019 à 17:55, Hervé BOUTEMY a écrit : > Putting that parameter as a pom property with a well known name and value > format permits to share the configuration between every packaging plugin. > This also has the advantage that child poms will inherit from parent value, > and eventually

Re: [DISCUSS] configuration for Reproducible Builds

On Sun, 29 Sep 2019 12:41:17 +0200, Enrico Olivelli wrote: Il dom 29 set 2019, 12:16 Robert Scholte ha scritto: I would think that all project.* properties represent the pom.xml and are immutable. To be more precise: the same pom.xml should effectively stay the same with every build.

Re: [DISCUSS] configuration for Reproducible Builds

Il dom 29 set 2019, 12:16 Robert Scholte ha scritto: > I would think that all project.* properties represent the pom.xml and are > immutable. To be more precise: the same pom.xml should effectively stay > the same with every build. > Instead this seems more related the (maven)session, right? >

Re: [DISCUSS] configuration for Reproducible Builds

Hi Hervé, On 29.09.19 11:19, Hervé BOUTEMY wrote: regarding the property name, I had an idea: why not do like we already did for ${project.build.sourceEncoding}, ie. mimic a future element in pom.xml, in build? could be project.build.timestamp? This sounds like the best idea... This

Re: [DISCUSS] configuration for Reproducible Builds

I would think that all project.* properties represent the pom.xml and are immutable. To be more precise: the same pom.xml should effectively stay the same with every build. Instead this seems more related the (maven)session, right? Robert On Sun, 29 Sep 2019 11:19:45 +0200, Hervé BOUTEMY

Re: [DISCUSS] configuration for Reproducible Builds

regarding the property name, I had an idea: why not do like we already did for ${project.build.sourceEncoding}, ie. mimic a future element in pom.xml, in build? could be project.build.timestamp? Le samedi 28 septembre 2019, 17:55:24 CEST Hervé BOUTEMY a écrit : > Achieving Reproducible Builds

Re: [DISCUSS] configuration for Reproducible Builds

very good question: this was a key question to me, that lead me to the PoC to test and see this PoC showed a basic fact: a POM will inherit the value from his parent Then once a parent POM has a "reproducibility" timestamp, child POMs inherit reproducible configuration, and can eventually