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
