There are some solutions/alternatives here: 1) Fixed value by default. 2) Warning to the user for having reproducible builds off. 3) Use the SCM last commit date.
I have worked a tiny bit for the Reproducible Builds effort so here is my 2 cents: * Using the SCM last commit date is a bad choice, not everyone will use SCM or the source code could be downloaded without scm information (eg.: Source Code download links from GitHub), so this is a -1 for me. * Throw a warning to the user to force the set of the project.build .outputTimestamp value is also a -1 for me, this reminds me of the project. build.sourceEncoding that was changed in Maven 4 to UTF-8 by default, and having that default value is the correct way to proceed instead of an ugly warning. * This leaves us with the fixed value by default, the current value (in the PR) is 2001-01-01T00:00:00Z.... this is a good approach, but my personal preference is to set it to 1980-01-01T00:00:02Z, the minimal date allowed. There should be a way to opt out of this and get the previous behavior for those that don't what this. As fo the release plugin, it should simply use the fixed date (if the property is not set), having a warning seem ugly the same way as the sourceEncoding warning was ugly. Now, in my experience, sometimes setting the outputTimestamp is not enought and is not a silver bullet to make a reproducible build. So just to be clear, what is the really the end goal of enabling it by default? I know the advantages and benefits, but what would be the goal of having this opt-out instead of having it opt-in? On Wed, Sep 25, 2024 at 11:03 AM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Le 2024-09-25 à 06 h 52, Mateusz Gajewski a écrit : > >> > >> 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. > > > (note: I'm duplicating here a comment I just made on the PR). I guess > that checksum is not a goal in itself, but the higher level goal is > security (checking that a JAR file has not been compromised)? If yes, > then we do not necessarily need bit for bit reproducibility. > "Semantically reproducible build" or "semantic equivalency" can be as > good or even better, as it does not force us to throw away useful > metadata like the real build time. Microsoft has short discussion about > semantic equivalency there: > > https://github.com/microsoft/OSSGadget/wiki/OSS-Reproducible > > Could the real issue be that we do not have a Maven plugin for making > semantic equivalency check easy? E.g. a plugin that build a project and > automatically compare semantically against the JAR file on Maven Central > or elsewhere? > > Martin > >
