Lockfiles also give client validations vs server checksums which are useless these days so it is important but I know Tamas did some other great hcking in resolver so highlightinhg resolver new features sounds great.
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le ven. 5 déc. 2025, 20:35, Manfred Moser <[email protected]> a écrit : > 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] > >
