And one more thing... Toolbox has two mojos, tree (the usual "tree" - project deps) but also plugin-tree (if unfiltered, will have multiple roots, one for each plugin) https://gist.github.com/cstamas/794d055a9dcd5ffe99b92bdcb4520686
Of course, these trees do NOT contain "dynamically resolved" things you mentioned. T On Wed, Jan 28, 2026 at 1:29 PM Tamás Cservenák <[email protected]> wrote: > > And to continue on this topic... > > As I said, there is a _list_ of all the materials needed for the build. > > But if you rebuild the project (let's use ipfs client as guinea pig) > with empty repo and reverse tree tracking enabled: > https://gist.github.com/cstamas/68c26d7d82ff5134eaf4c311944e28bb > > You will end up (with incomplete, but is better than nothing) > information stored in local repo (as .tracking) why each artifact is > here. > So to say, with tree branches.... > > For example: org.jetbrains.annotations is here due > https://gist.github.com/cstamas/51ef4515b79ae0fb13360ba379ed6eb6 > > Or java-multibase is here due: > https://gist.github.com/cstamas/5cfc38c5484a86598303825eb379aa3e > > etc > > > On Wed, Jan 28, 2026 at 12:59 PM Tamás Cservenák <[email protected]> wrote: > > > > Howdy, > > > > Nice to hear from you Adam! > > > > I was recently involved in a project where PO wanted "fully locked > > down" build, and he got it: > > https://github.com/ipfs-shipyard/java-ipfs-http-client > > > > (this project depends on a handful of small other projects, and we had > > a "release spree" to modularize those too -- not much important). > > > > But this "fully locked" (using TC feature) showed two interesting > > side-effects: > > > > First is obvious: > > https://github.com/ipfs-shipyard/java-ipfs-http-client/pull/273 > > Dependabot generated PR must have human assistance (as by def they > > fail, as expected, since checksums drift with update). > > Hence, a subsequent human made (and verified) commit is a must to make > > it mergeable. > > > > Second was less obvious and more a surprise (due "black box" nature of > > service they use for releases -- I am pushing them toward Central > > publishing): > > https://jitpack.io/#ipfs-shipyard/java-ipfs-http-client > > The release 1.5.0 _failed_ with this in log: > > https://jitpack.io/com/github/ipfs-shipyard/java-ipfs-http-client/1.5.0/build.log > > (my release attempt comments may be tracked here > > https://github.com/ipfs-shipyard/java-ipfs-http-client/issues/271) > > In short: fully locked down build in this way _refuses_ to resolve > > ANYTHING not in checksums. As can be seen, Jitpack > > seems to have tried to invoke (undocumented, I did not find anything > > about this in their doco, nor I have idea why they use ancient plugin > > version from 2014) > > exec-maven-plugin, and resolver refused to resolve it. > > > > In fact, with this project fully locked down, the only way to invoke > > ad-hoc plugins on them is possible only if you lax TC, like this: > > https://gist.github.com/cstamas/e21cfe67a35dab4c07f6ca7e3fc1419d > > > > But, the consequence, and on tangent to what you say, checksums file > > must list everything that is getting resolved via Resolver, hence, > > even the surefire dynamically resolved JAR (check it out, it is there > > too). > > In other words, these files list _everyting_ you need for the build: > > https://github.com/ipfs-shipyard/java-ipfs-http-client/tree/master/.mvn/checksums > > > > We for sure need to work on this more... (and ideas welcome!) > > > > For start, latest resolver will have this: > > https://github.com/apache/maven-resolver/commit/645cb05b068dd17121c09e374cde69eefd7aca70 > > As today, TC are "all or nothing" (as can be seen on example project > > above; even plugins and ad-hoc plugin invocations are subjected to > > it). > > The idea here is to limit TC to "project dependencies" only... we have > > members questioning this, as plugins can be targeted by supply chain > > attack just like dependencies can, but the intent here is to leave > > some leeway to users. > > > > Happy to continue on this topic! > > > > PS: No, Maven4 in this regard received no substantial change (yet) > > > > > > > > > > On Wed, Jan 28, 2026 at 12:34 AM Adam Kaplan <[email protected]> wrote: > > > > > > A bit late on this thread, but I felt compelled to respond as one of the > > > contributors to such a "Maven Lockfile" plugin [1]. I also work for Red > > > Hat, where we too rebuild artifacts published on Maven Central. > > > > > > Tamas touches on one of the features of a lockfile - checksums - which > > > many > > > package ecosystems also implement. The trusted checksums demo [2] > > > implements similar functionality as the Go programming language's `go.sum` > > > file, and I agree that the checksum problem is "solved" at the aether > > > resolver level. It's less clear to me if this feature set will be exposed > > > through a direct Maven configuration option in 4.x - is this on the > > > roadmap? > > > > > > That said, from my perspective the listing and validation of checksums is > > > a > > > small feature of a build lockfile. The more important feature of any > > > lockfile is a transparent and complete dependency tree that can be > > > validated at build time. These dependency trees, in turn, can be used to > > > generate an accurate software bill of materials (SBOM). Hermetic > > > (“offline”) builds that pre-fetch the dependencies in lockfiles can > > > further > > > validate the completeness of any generated SBOM. This is the philosophy of > > > the Hermeto project, which I am also involved in [3]. > > > > > > Unfortunately obtaining a complete dependency tree a-priori in Maven is > > > exceptionally hard, and perhaps impossible in the general case. Many > > > plugins dynamically fetch dependencies for the sake of developer > > > convenience - even the Surefire plugin does this as a feature [4]! In > > > today's era of open source software supply chain attacks and regulatory > > > requirements for accurate SBOMs, I think any plugin feature that > > > dynamically obtains dependencies needs to be reconsidered. Unfortunately > > > there is no way to roll back such behavior without causing enormous > > > disruption to the Java ecosystem at large. > > > > > > [1] https://github.com/chains-project/maven-lockfile > > > [2] https://github.com/cstamas/tc-demo > > > [3] https://hermetoproject.github.io/hermeto/ > > > [4] > > > https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html > > > > > > On Sun, Dec 7, 2025 at 6:37 PM Tamás Cservenák <[email protected]> > > > wrote: > > > > > > > Howdy, > > > > > > > > Tried to gather some "bigger picture" around this topic: > > > > https://maveniverse.eu/blog/2025/12/06/lockfiles/ > > > > > > > > Thanks > > > > T > > > > > > > > On Sat, Dec 6, 2025 at 1:19 PM Elliotte Rusty Harold > > > > <[email protected]> > > > > wrote: > > > > > > > > > > On Fri, Dec 5, 2025 at 7:36 PM Manfred Moser <[email protected]> > > > > wrote: > > > > > > > > > > > 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. > > > > > > > > > > I wouldn't expect checksums to match in a scenario like that. A > > > > > different entity is rebuilding the project with a potentially > > > > > different compiler, JDK, and chain of trust. I maybe don't want those > > > > > checksums to match. > > > > > > > > > > > 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. > > > > > > > > > > Again, I think that's working as intended. Shading changes the binary > > > > > code that's running. It shouldn't have the same checksum. > > > > > > > > > > -- > > > > > Elliotte Rusty Harold > > > > > [email protected] > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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] > > > > > > > > > > > > > > -- > > > > > > Adam Kaplan > > > > > > He/Him > > > > > > Senior Principal Software Engineer > > > > > > Red Hat <https://www.redhat.com> > > > > > > 100 E. Davie Street > > > > > > [email protected] > > > <https://www.redhat.com> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
