Hervé>Maven core itself can be built in a reproducible way!
This is nice, thank you for pushing this.
It would be really great if Maven plugins defaulted to reproducible artifacts as well (e.g. maven-jar produced a jar with sorted entries and fixed timestamps).
Hervé>Interested in joining the effort to bring this feature to releases for end users?
Does that include reproducible source releases?
It would help to verify them and vote on releases as well, as everybody could build their own copy of Maven and check if the resulting archive is the same as the one that is proposed for the release.
Hervé>- do you build on Windows or any Unix? This impacts newlines...
Can the build enforce certain newlines? For instance, *.sh scripts have to be LF no matter what the build OS is.
The same goes for *.cmd which have to be CRLF and so on.
I've implemented reproducible builds for Apache JMeter, and one more variable is "executable bit".
Git on Windows often produces "executable readme.txt" and things like that, so JMeter's build script enforces executable bits for the resulting archives.
One more variable is "the state of Maven local repository". In other words, if I `mvn install` a library (e.g. while hacking on commons-io), then Maven build would pick that library from my .m2 folder, and it would be included to the Maven build which is bad for reproducibility.
That could have been prevented by pgpverify-maven-plugin which could verify that dependencies have expected PGP signatures.
Apparently my own commons-io build could not have the proper PGP signature, so Maven could warn me like "hey, you're using unexpected commons-io.jar".
I've tried mvn install -DskipTests on my macOS machine, and the result differs
Here's output of mvn clean install -DskipTests -Papache-release:
Le 23/09/2019 à 01:52, Hervé BOUTEMY a écrit :
> after a few years of testing, thinking, procrastination and hard work (thank you Thomas for your talk at Devoxx France 2016 ), I think I achieved a key step this week-end toward native Reproducible Builds with Maven : Maven core itself can be built in a reproducible way!
An important milestone on a very long journey. Well done!
To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]
Oh right! I missed the second half of our pom.deps file:
blacklisted org.hibernate:hibernate-ehcache:4.2.19.Final from
deprecated org.hibernate:hibernate-search-engine:4.4.0.Final from
resolved org.hibernate:hibernate-search-orm:4.4.0.Final from
locked org.hibernate:hibernate-validator:4.3.1.Final from
I provide 4 types of resolution, deprecated/blacklisted means the build
will fail, unless you specifically opt-in to deprecated/blacklisted
On resolve, anything that's changed moves from `locked` to either
resolved/deprecated/blacklisted, and on release anything resolved goes
In the end user projects, we "import" the bill of materials .deps
artifact which pulls in any locked version, but I also have support for
allow unlocked /^.*someregex.*$/;
which will trigger a re-resolve, which we use for our own internal
artifacts, so we pick up the latest internal releases IF we re-resolve.
The whole process seems to work well, it does cause some annoying round
trip releases or quirks now and then, but for the most part - it's
really solved a heap of issues where we've needed to back a quick
backport fix in a production environment.
Since we publish the pom.deps file for each artifact, when doing the
backports, we simply import the deps used in the distribution version
we're patching, and manually allow any updated deps that we need to fix.
Tomo Suzuki wrote:
> For reproducible builds, I expected the lock file contains specific
> versions, rather than ranges. Would you share the background why your tool
> records the ranges?