Caveats from that document, top one basically blows this whole thing up.

Maven can't give you reproducible builds with version ranges, because it has no lockfile.

---

More Details Reproducible Builds for Maven:

Require no version ranges in dependencies, Generally give different results on Windows and Unix because of different newlines. (carriage return linefeed on Windows, linefeed on Unixes) Generally depend on the major version of the JDK used to compile. (Even with source/target defined, each major JDK version changes the generated bytecode) For detailed explanations, see Maven “Reproducible/Verifiable Builds” Wiki page.

I would say that is a reasonable constraint. As you know, version ranges, and other "dynamic" versions in Maven are inherently incompatible with reproducible builds because they are resolved non-deterministically during the build. The most common approach when reproducibility is required is to resolve dynamic dependency versions in source, which is a strategy shared by tools that use lockfiles.

I agree that Maven would be better with lockfile support. However, as with any proposed evolution of Maven, I can imagine it would be quite hairy to implement in a way that is compatible with other mechanisms.

On the other listead caveats, I would add:

- Output line endings are controllable via line.separator, which Maven honors. Input line endings are an important consideration for reproducibility, but also not truly a problem of Maven's reproducibility.

- JDK version can be enforced with Maven Enforcer and/or toolchains.