Excellent news on the trusted checksums feature! As this appears to be provided by Maven itself (in 3.9 onward?), is this the recommended way for teams to version Maven checksums in git? If so, is more documentation planned/needed?
Perhaps what is missing in maven-dependency-plugin is machine-readable output for the `resolve-*` goals, akin to what is generated by `tree` with the `outputType` configuration option [1]. A fully resolved set of dependencies (with their transitive dependencies) in JSON or XML with their download URL, checksum, and other related information would allow other tools to reproduce a build with their exact dependencies. Hermeto (a tool my employer, Red Hat, maintains) provides a concrete use case for having such a machine-readable file versioned in git [2]. We use this tool to pre-fetch dependencies prior to running builds in a network-isolated environment. Maven's lack of a comprehensive lockfile (or equivalent set of files, as exists in the Go programming language) is a barrier to supporting it as a "package manager." A JSON-formatted list of dependencies from `dependency:resolve` or `dependency:go-offline` would potentially unblock this feature [3]. [1] https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html#outputType [2] https://github.com/hermetoproject/hermeto [3] https://github.com/hermetoproject/hermeto/issues/664 On 2025/07/11 15:18:15 Tamás Cservenák wrote: > Howdy, > > Yes, sadly we (project) are very bad at "advertising" and "properly > documenting" things. Sorry about that. > > Trusted checksums is in fact SPI and one can plug in various sources > (while resolver contains some "basic" implementations). This is a very > similar setup as with Remote Repository Filtering (RRF, > https://maven.apache.org/resolver/remote-repository-filtering.html) it > is also SPI + "basic" example implementations. > > For example, Maveniverse Mimir is a checksum provider for Maven too: > https://github.com/maveniverse/mimir/blob/639f49f4d6e763cbcdfc7b29dc69f0eb22c345f1/extension3/src/main/java/eu/maveniverse/maven/mimir/extension3/MimirTrustedChecksumsSource.java#L31 > > It just hook into SPI: > https://github.com/apache/maven-resolver/tree/a60ebd1a6cd1d40019303b8bbee5b601f8e33d0a/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/checksums > > Also, there is my personal "demo" but most probably I need to update it: > https://github.com/cstamas/tc-demo > > In this case, the "checksums source" (file) is checked in with > sources/project files, the most basic setup (as hopefully you trust to > repo you are building sources from, hence you should trust the > checksums enlisted as well). > > Thanks > T > > On Fri, Jul 11, 2025 at 4:57 PM John Neffenger <jo...@status6.com> wrote: > > > > On 7/11/25 7:26 AM, Calum Harrison wrote: > > > "Trusted Checksums" is good to know about -- I had missed that. > > > > It's very easy to miss! > > > > I came across it accidentally myself rather recently. I was > > participating in this issue: > > > > [MNG-6026] Extend the Project Object Model (POM) with trust information > > (OpenPGP, hash values) #7858 > > https://github.com/apache/maven/issues/7858 > > > > but I missed the post by Tamás Cservenák that announced it: > > > > Maven OOTB provides: trusted checksums ... > > https://github.com/apache/maven/issues/7858#issuecomment-3041224404 > > > > Gradle has had similar dependency verification for some time: > > > > Verifying dependencies > > https://docs.gradle.org/current/userguide/dependency_verification.html > > > > The corresponding Maven documentation is found at the link below. The > > Maven page looks more like an internal design document, which is > > important, but we're missing a good description of the end-user interface. > > > > Expected Checksums > > https://maven.apache.org/resolver/expected-checksums.html > > > > This is a long-awaited major new feature and enhancement. It seems that > > very few users of Maven are aware of it. > > > > John > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
