I would say that is a reasonable constraint. As you know, version ranges, and other "dynamic" versions in Maven are inherently incompatible with reproducible bu

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.