[MNG-6789] Make Maven distribution build Reproducible

[jira-importer]

Hervé Boutemy opened MNG-6789 and commented

with Maven native Reproducible Builds near available, it would be great to have Maven itself being the first Maven project that gets Reproducible Builds

there is already a proof of concept available in reproducible branch: https://github.com/apache/maven/tree/reproducible with corresponding Jenkins build https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/

once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a reproducible release available, the last 2 plugins that bring non reproducible result in this build are plexus-component-metadata 2.0.0 and sisu-maven-plugin

---

Affects: 3.6.2

Issue Links:

• MNG-6580 Unable to inject annotations from classes compiled for Java 9+

• MNG-6512 Checking possibility to require Java 11 to run Maven

• MNG-6276 Support Reproducible Builds (https://reproducible-builds.org)
  ("requires")

• MNG-6799 avoid model interpolation instability risk: ensure StringVisitorModelInterpolator replaces StringSearchModelInterpolator
  ("requires")

• MASSEMBLY-921 Reproducible Builds: make entries in output archive reproducible (order + timestamp)
  ("depends upon")

• MJAR-263 Reproducible Builds: make entries in output jar files reproducible (order + timestamp)
  ("depends upon")

• MSOURCES-120 Reproducible Builds: make entries in output jar files reproducible (order + timestamp)
  ("depends upon")

• MNG-6859 Build not easily reproducible when built from source release archive
  ("depends upon")

Remote Links:

• sisu.inject PR #5
  
• plexus-containers plexus-metadata issue #27
  

[jira-importer]

Hervé Boutemy commented

fixed in bd10f00b68eb766cd239275e8504acedc2818d69

[jira-importer]

Michael Osipov commented

Hervé Boutemy, do you think it is worth to do this:

diff --git a/maven-core/src/main/resources/org/apache/maven/messages/build.properties b/maven-core/src/main/resources/org/apache/maven/messages/build.properties
index 20f386ba0..8725e70bd 100644
--- a/maven-core/src/main/resources/org/apache/maven/messages/build.properties
+++ b/maven-core/src/main/resources/org/apache/maven/messages/build.properties
@@ -16,6 +16,7 @@
1. under the License.

 buildNumber=${buildNumber}
+timestamp=${project.build.outputTimestamp}
 version=${project.version}
 distributionId=${distributionId}
 distributionShortName=${distributionShortName}

?

[jira-importer]

Hervé Boutemy commented

at least, it does not break reproducibility: I'm not against from this point of view
is it worth to do it? I really don't know.
Thinking at it, I prefer to not have a "timestamp" property in build.properties that does not really represent the timestamp of the build: now that we have reproducible build, the timestamp of the build is something a notion that does not have any interest since we get the same result whenever the effective build is done

[jira-importer]

Michael Osipov commented

Agree, but that would depict when the release has been rolled and has not been changed compared to Git.

[jira-importer]

Hervé Boutemy commented

if you want: just create a separate Jira issue, please

[jira-importer]

Hervé Boutemy commented

notice: the timestamp value is accurate for releases, but not for SNAPSHOTs, where its value will be the timestamp of the previous release

[jira-importer]

Michael Osipov commented

I completely forgot this. In this case the value would be wrong. I will leave it as-is.