On Wed, Sep 25, 2024 at 5:58 AM Christoph Läubrich <m...@laeubi-soft.de> wrote:
> > yes, this is the idea: there is no other option I can imagine to get > a reproducible zip entries timestamp, whatever the precise value of the > timestamp it is > > If anybody has any other algorithm idea (that supports wide reality > of situation: not everything is built from Git, for example), I'm all > ears open > > For me this looks more like an issue of the jar plugin and should > probably be handled there, then even though I wonder why the zip entries > need a timestamp for a jar to be reproducible, should it not be enough > to compare the zip-entries and leave the timestamp alone? > The idea of a reproducible build is to create binary exact artifacts which you can quickly calculate checksum to compare with some reference build. As the timestamp entry is used in zip/JARs, it changes the binary representation of a jar as well. So yeah, that's important. > > Am 24.09.24 um 22:54 schrieb Herve Boutemy: > >> Or is the idea to have a *fixed* *default* timestamp for all builds? > > > > yes, this is the idea: there is no other option I can imagine to get a > reproducible zip entries timestamp, whatever the precise value of the > timestamp it is > > > > If anybody has any other algorithm idea (that supports wide reality of > situation: not everything is built from Git, for example), I'm all ears open > > > > if people want to discuss the exact default value chosen, we can also: I > don't care about this value, it just has to be defined > > > > Regards, > > > > Hervé > > > > On 2024/09/24 11:49:45 Ceki Gulcu wrote: > >> > >> Hi Hervé, > >> > >> > >> In my opinion, the value of <project.build.outputTimestamp> should be > >> part of the pom.xml file and thus visible after the build. Otherwise, > >> how can the build be reproducible? > >> > >> Or is the idea to have a *fixed* *default* timestamp for all builds? > >> > >> -- > >> Ceki Gülcü > >> > >> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch > >> > >> > >> > >> On 24/09/2024 11:21, Olivier Lamy wrote: > >>> Hi > >>> It looks like you have some comments on the PR :) > >>> I know it's been implemented as is for a long time now, but I wonder I > >>> (and it looks like a few others) wonder if we could avoid this > >>> "random" build timestamp. > >>> > >>> > >>> On Tue, 24 Sept 2024 at 17:05, Hervé Boutemy <herve.bout...@free.fr> > wrote: > >>>> > >>>> everything is in the title > >>>> > >>>> Jira issue is https://issues.apache.org/jira/browse/MNG-8258 > >>>> PR is https://github.com/apache/maven/pull/1726 > >>>> > >>>> WDYT about merging this PR as part of the Maven 4 global update? > >>>> > >>>> Regards, > >>>> > >>>> Hervé > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
