Michael and John, I think Maven might need lock files for fully reproducible builds.
Michael, I agree with your statements about discouraged version changes use and not such things as the quicksand of "latest".
However I also see a need for specific locking to checksums of artifacts. Both approaches from chains-project and from Tamas directly in aether are valid and useful. Let me explain my scenario.
I work for Chainguard and we are rebuilding artifacts from source within our infrastructure and create completely trusted binaries with SLSA and SBOM info and more and provide these binaries and supplementary files to our customers. Because Maven (JAR and others) builds are often not reproducible in terms of leading to exact same checksums (unless a project set it up to wipe timestamps and such) our binaries do have different checksums from the ones supplied via Maven Central.
A lockfile could be used as a signal to track exact dependencies and therefore be seen as another step to a fully reproducible build.
At the moment even reproducible builds are not necessarily reproducible when it comes to shading classes into other jars and the exact dependencies being used when creating tarballs or whatever with JARs inside with the assembly plugin for example.
Given that we already have a workable setup from Tamas I think it would be good to pull this into Maven itself and talk about it more. And maybe do it as an optional thing for starters... from my work in the JS and Python and Ruby communities I have seen that lock files can be a be a massive pain to deal with as well so optional sounds better to me
Thoughts? Manfred On 2025-12-05 09:49, Michael Osipov wrote:
On 2025/12/05 17:26:06 John Neffenger wrote:Could we list the Maven Trusted Checksums feature [1] among the top features, if not *the* top feature, of Maven 4? Such dependency verification is a critical requirement in a build tool for those working to prevent supply chain attacks, but the feature is completely unknown among that group. Just today, a paper [2] was posted to the Reproducible Builds mailing list that states: "Meanwhile, Maven, the other major package manager for Java does not have a lockfile at all. We recommend the Maven community to add this feature and learn from the best practices to design an informative and usable lockfile." The paper explains, "Lockfiles are used to reduce build times; to verify the integrity of resolved packages; and to support build reproducibility across environments and time." I think the Trusted Checksums feature satisfies that definition. Other projects that seek to provide Maven Lockfiles [3] were also unaware of the built-in support for dependency verification in Maven version 3.9.2 back in September 2024. This major new feature has failed to be noticed. Can we increase its visibility when Maven 4 is released? And perhaps we should call them Lockfiles. :-)I gained some experience with uv and Cargo recently and need to tell you that we don't need a lock file (at all) because we don't have the same concept as others tools have. I will elaborate: * We don't encourage to use ranges or even open ranges like foo, foo>=1.5, etc. We always use fixed versions. Both LATEST and RELEASE are not recommended. * Every dependency is tied to a repo in a custom properties file written by Resolver. Maven won't download from another repo. * As you said, you can provide all checksums. You basically have all you need what Cargo.lock or uv.lock are doing. I personally even dislike uv's default index strategy compared to Maven or pip. Michael --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
