Unpacking lockfiles in different package managers

John Neffenger john at status6.com
Mon Dec 8 19:12:43 UTC 2025


On 12/5/25 5:17 AM, Benoit Baudry wrote:
> Shall this ring a bell don't hesitate to reach out

The paper prompted a discussion on the Maven Developer List and a good 
article by the Maven Trusted Checksums author, Tamás Cservenák:

Lockfiles
https://maveniverse.eu/blog/2025/12/06/lockfiles/

Thanks for starting the conversation!

Now that I've read the paper, I have two comments regarding its 
"Recommendations for package manager developers."

1. Recommendation #4 says, "At the other extreme, Gradle presents a 
serious lockfile anti-pattern by omitting essential details such as 
checksums."

Yet Gradle *does* have checksums for dependency verification. Here is 
the checksum file that we use in the JavaFX project:

openjdk - jfx/gradle/verification-metadata.xml
https://github.com/openjdk/jfx/blob/master/gradle/verification-metadata.xml

The Gradle developers considered the locking of versions and the 
verification of dependencies to be "orthogonal" [1], so they implemented 
them separately. But the checksum feature is present, as it is for Maven.

2. Recommendation #5 says, "On the other end, when the lockfile is not 
generated by default, as with Gradle, developers seldom use them."

Rather than because of Gradle defaults, in my experience, Java 
developers don't use lockfiles because they don't use ambiguous versions 
for their dependencies in the first place. They specify exact versions 
in the build file ('build.gradle' or 'pom.xml'), so the build file 
itself is essentially the lockfile. Then, for security reasons, they add 
dependency verification using the checksum features of Gradle or Maven.

Tamás discusses this further in his blog post linked at the top, 
including the pitfalls of doing this only through "best practices."

John

[1]: https://github.com/gradle/gradle/issues/5633#issuecomment-395323940



More information about the rb-general mailing list