...

• Drop the Maven/JDK version numbers in MANIFEST: most of the time you should get exactly the same result with two different versions of Maven and/or JDK (if you keep the same major version number). But you have to restrain to a given OS family because of line endings. However, with the new development roadmap of OpenJDK (2 "major" versions per year, each one increasing the class file version number), it may be difficult to find 2 versions of javac that produce the same class files in the near future.
• Keep the version numbers in the MANIFEST: there are not easily accessible here. Moreover the semantic is poor (e.g. there is no JDK vendor so you can have different results if you use OpenJDK/Oracle JDK/Eclipse compiler, no reference of the Operating System used for line endings).
• Add a "reproducible build bill of materials" in an external file. This is the way Debian took to manage reproducible builds: they record the "build environment" in an external ".buildinfo" file that has all the information required to reproduce the build environment. If the frame of Maven we can think of several ways to achieve that (non-exhaustive list):
  • Create a secondary artifact (e.g. *-buildinfo.xml) with the required information
  • "Patch" the published pom file to add properties with the required information, something like:

<properties>
  <maven.reproducible.build.maven.version>3.5.0</maven.reproducible.build.maven.version>
  <maven.reproducible.build.jdk.version>8u123</maven.reproducible.build.jdk.version>
  <maven.reproducible.build.jdk.vendor>openjdk</maven.reproducible.build.jdk.vendor>
  <maven.reproducible.build.arch>amd64</maven.reproducible.build.arch>
  <maven.reproducible.build.os>linux</maven.reproducible.build.os>
</properties>

Another way to ease the reproducibility would be to use a wrapper script that would download from Maven Central the exact Maven & JDK versions that should be used to build the project. It is the same kind of idea than the maven-wrapper tool, but extended to the JDK itself. This feature would also benefit people not interested in reproducible builds because it would ease the computer setup of every developer and erase most of the discrepancies between developers builds and CI builds.

What are the issues to solve?

...