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!
It means that if you build "reproducible" branch of Maven core, you'll get the same apache-maven-3.6.3-SNAPSHOT-bin.zip than me or the ASF CI server .
The precise result depends only on 2 key facts:
- do you build on Windows or any Unix? This impacts newlines...
- what JDK major version do you use to build? This affects generated .class (notice: AFAIK minor JDK version does not have any impact, nor platform)
This branch is only a PoC: it uses unreleased packaging plugins that give reproducible results (versions in .RB-SNAPSHOT), and I had to tweak a little bit the build for remaining reproduciblity issues with sisu and plexus plugins.
There are many details to decide before releasing these plugins and making every build reproducible by default.
But the current steps proves that is is feasible.
Interested in joining the effort to bring this feature to releases for end users?
> but internally we have a tool I
> wrote for handling this, we have a pom.deps file that looks like:
nice separation of concerns: stable versions chosen vs updates controlled with ranges
with such an approach, version ranges could become something I love :)
> repository http://nexus.XXXXXX as public;
> import smx3:smx3.upstream.bill-of-materials:1.1.22;
> resolve highest org.jetbrains:annotations:[16.0.3,17.0.0) via public;
> resolve highest
> org.apache.maven.plugins:maven-jar-plugin:[3.1.2,4.0.0) via public;
> resolve highest org.apache.cxf:cxf-codegen-plugin:[3.3.3,4.0.0) via
> which when we resolve, will find the highest, snapshot, or lowest
> version in a given range - also allowing filtering out annoying things
> like beta/alpha/CR from central, and rewriting the pom.xml's.
> Our tooling also has an 'import' option shown above that lets us
> standardize the versions we resolving, and breaking it up - so we have
> 'upstream.bill-of-materials' and 'upstream.testing.bill-of-materials`.
> As part of this we also add in <exclusions> to ban all transitive build
> deps, and  range all version references.
> I keep meaning to push for open sourcing it, but just haven't had the time.
To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]
Basically to be included in preparationGoals/completionGoals using the apply/clear goal in each.
So far based on very quick, rudimentary tests this seems to work well (altho I've not yet done it as part of a release, but using apply and then building/checking my jars.
I'd be keen on any feedback...
Interestingly, whilst the class files INSIDE the jar have the correct date, the jar this has todays - which makes sense, but I wonder if it shouldn't be the same time for one extra step of "the exact same output"...
"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.