[rb-general] Checking Reproducible Build for a Maven project

[Hervé Boutemy]

trying to compare results from multiple build tools was perfect for our first 
tests in Marrakesh on a very basic build, but it is not something that will 
happen in real life with any real project or any more complex build.

But I completely see how you find it useful to easily have multiple build 
outputs to compare against each other.
It's currently what is painful to me:
1. building multiple times on my computer, saving each output each time to 
investigate if there are any differences
2. building on another computer, with another OS, and comparing against the 
other computer if there are any differences
3. trying to get other people rebuild on their own configuration to compare 
against my results and share their results

This is why I wrote maven-buildinfo-plugin, to ease comparison in more complex 
cases (for example multi-module builds), and I'm trying to have other Maven 
contributors rebuild and compare buildinfo output.
But at the moment, nobody tried to rebuild: looks like I'll have to add the 
buildinfo publication and control in normal release process to have a chance 
someone will share his rebuild result... Even at that point, I'm not sure it 
will happen, because the feedback will have to be shared by email on a 
mailing-list.

I'm still stuck on an easy way for rebuilders to share their results.

Regards,

Hervé

Le jeudi 19 décembre 2019, 11:35:27 CET Hans-Christoph Steiner a écrit :
> Another thing I'd like to add:
> 
> I have found that in the process of trying to reproduce builds on a
> rebuilder, there are various issues that come up due to the build
> dependencies.  I have found one helpful way to work through those is to
> build the library with the various build tools.  I think it is
> feasible to get multiple build systems making the exact same files, when
> the library is a plain collection of Java classes.
> 
> The sad side is that it seems that the reproducibility of JARs is quite
> sensitive to which JDK/version was used to build it, even if they are
> all all set to generate Java8 bytecode.
> 
> .hc
> 
> Hans-Christoph Steiner:
> > More progress!  The jtorctl library that we hacked on in Marrakesh is
> > now published using Maven with a .buildinfo file:
> > 
> > https://repo1.maven.org/maven2/info/guardianproject/jtorctl/0.4/
> > 
> > .hc
> > 
> > Hans-Christoph Steiner:
> >> After working with Maven and Bazel devs at the summit,  I wanted to
> >> follow up to keep the buildinfo work moving.  I have buildinfo
> >> generation working with gradle, and it is now working in Maven plugins.
> >> 
> >>  I'd heard it was working with Bazel, but I haven't seen it yet.
> >> 
> >> The JARs produced with Maven and Gradle now only differ in the sort
> >> order of files in the ZIP header.  `mvn deploy` even pushes the
> >> buildinfo file to the maven repo:
> >> https://gitlab.com/eighthave/jtorctl/-/packages/59404
> >> 
> >> In this process, I found a small bug in maven archiver, which puts the
> >> META-INF/ dir entry after the META-INF/MANIFEST.MF entry in the ZIP:
> >> https://issues.apache.org/jira/browse/MSHARED-849
> >> 
> >> .hc