Howdy,
And one more thing: Started an email, and realized we have no doco for
it, so I tried to document "how resolver works" (high level, but also
to align lingo, so we all know what we talk about) here:
https://github.com/apache/maven-resolver/pull/1794
But it is still WIP. But in short, the "resolve" process is series of
steps like:
1- collect GAV: GAV => "depNode dirty graph" (may have cycles, is not
a tree) -- two collector implementations exists since maven 3.9+, the
old DepthFirst and new BreadthFirst (default in mvn4). This step also
implicitly invokes step 4 to get needed POMs to build eff models to
"crawl" upon.
2- conflict resolution (selects "winners", removes cycles, makes graph
a tree): "depNode dirty graph" => "depNode tree" (no cycles) -- two
conflict resolvers exists in Maven 4 ("legacy" and new "path based")
3- flatten tree (in 3 possible ways: pre-order, post-order and level
order) "depNode tree" => "RGAV list"
4- resolve artifacts "RGAV list" => files (usually pointing to local
repo) -- this is where JARs are downloaded (if needed) <- TC hooks
into here, so everything, JAR, POM that "goes thru" resolver is
enforced (latest resolver 1/2 has "scope" support, so may enforce all
as today, or only "project deps")
Note 1: step 1, 2 and 3 operates on _models_ only (not only POMs, but
effective models built out of POMs, hence parents, imports, etc), no
JAR is pulled/used in any of these steps. Also, Maven lingo calls
steps 1 and 2 "collect/collecting" and steps 3, 4 "resolving" (same if
all steps 1,2,3,4 happens as one call, as Repository System has
several entrypoints, some do 1-2, some do 3-4 and some do 1-2-3-4 as
one call).
Note 2: step 3 produces also "classpath order" of artifacts, and for
example this is where Maven 3 and Maven 4 differ: Maven used
historically pre-order, but Maven 4 uses level order (nodes closer to
tree root are closer to resulting list head).
Note 3: step 2 also supports different strategies for winner
selection, maven3 used "nearest" (closest to root), while maven 4
supports "highest" (as per comparable Version for same GA) strategy as
well
Note 4: ongoing experiment with "dependency management": they are
historically black/white (managed or not managed, managed ==
enforced), ongoing experiment is adding "management advice"
https://github.com/apache/maven-resolver/pull/1613 (so making it tri
valued: unmanaged, advised, managed), adding a "middle ground" value
between values existing today
Note 5: once "advise" is in place, next logical step is to provide
"platform support", with initial idea is that resolver may (partially
or completely) repeat steps 1-2, if conflict resolver deems it
necessary (work is heavily cached, so doing that would not introduce
huge performance penalty)
Note 6: the mentioned missing piece from lockfile support blog,
ranges, should be covered by platform as well (as again, platform as
such may be "enforced" or "advised" or "aligning" etc -- brainstorming
still)
As you see, we are currently focusing quite a lot on this aspect of
resolver. But, due our own strict backward compatibility policy (see
https://maven.apache.org/resolver/upgrading-resolver.html and
https://maven.apache.org/resolver/api-compatibility.html for our
promises) all these may not happen in Maven 4 (or 4.1+) as features
may require some changes not being aligned with Maven 3/Resolver 1
APIs, while Maven 4 must remain compatible with Maven 3 (be able to
run Maven 3 plugins).
Thanks
T
On Wed, Feb 11, 2026 at 11:26 AM Tamás Cservenák <[email protected]> wrote:
>
> And one more thing,
> there is also "stat" sink used by default on some toolbox mojos, for example:
> https://gist.github.com/cstamas/428ed903b000eb23fd0910be42141be0
>
> Thanks
> T
>
> On Wed, Feb 11, 2026 at 11:02 AM Tamás Cservenák <[email protected]> wrote:
> >
> > Howdy,
> >
> > personally I keep these two split, for a reason:
> > - GAV w/ checksum
> > - tree
> >
> > for a reason. Our example, the IPFS repo we talk about, locks down
> > everything (that maven resolves during build).
> > For example, if you look at checksums file (using permalink of current
> > state of affairs):
> > https://github.com/ipfs-shipyard/java-ipfs-http-client/blob/2523fb26386ad1a94bda11d5277d6f59eaca470c/.mvn/checksums/checksums-central.sha512
> >
> > 1) There are two commons-codec versions (do a search in the browser
> > for "commons-codec/commons"), version 1.19.0 and 1.20.0, while the
> > project itself does not depend on any of these. These are in fact
> > dependencies on some plugins used in the build.
> >
> > 2) There are 11 ASF parent POMs! (do a search in the browser for
> > "org/apache/apache"). Again, the project is not an ASF project, these
> > parents are used by various ASF Maven core plugins!
> >
> > For case 1) that is an artifact, but again, project is not even using
> > it (build is), for case 2), project is not even in "control", as
> > parent POMs are pulled during model building.
> >
> > To look into tree, I usually use these commands (after successfully
> > built project w/ checksums enforced -- so I know all is right and in
> > place):
> >
> > https://gist.github.com/cstamas/585b21880ff1e05606bb70c97dec938a
> >
> > Nota bene: room for improvement, I need to pass in
> > `-Daether.artifactResolver.postProcessor.trustedChecksums=false` to
> > temporarily disable TC post processor (that performs checksum
> > validation) as project configures resolver in full lock down mode, so
> > even ad-hoc plugin invocation is impossible!
> >
> > In gist above there are 4 invocations:
> > tree, tree-find, plugin-tree and plugin-tree-find
> >
> > With these it is easy to figure out 1), to find where is commons-codec
> > used (where it is not used, and where it is used)
> >
> > For 2), as it is "meta" even in Maven (model builder "crawls" model
> > and asks models for resolution) are not. But, they are still
> > protected, as they also go through Resolver, as parent POM is a very
> > nice attack vector as well.
> >
> > As you see, the same GAV may appear in multiple places and contexts.
> >
> > All in all, consequences:
> > - if I download full TC list, I have everything I need for the build
> > (even offline)
> > - the TC list consolidated and made unique, to place them in tree, I
> > use alt tools
> >
> >
> > Refs:
> > https://maveniverse.eu/docs/toolbox/plugin-documentation/plugin-info.html
> >
> > On Tue, Feb 10, 2026 at 4:53 PM Adam Kaplan <[email protected]> wrote:
> > >
> > > Consolidating a bit of the discussion in this thread.
> > >
> > > On the topic of Java modules being a solution:
> > >
> > > Looking at Maven configuration would be needed
> > > > only if, after building the dependency tree, we want complementary
> > > > information such as version numbers (when not declared in the
> > > > `module-info`) and from which repository the dependency was downloaded.
> > >
> > >
> > > This is precisely what is needed to produce an accurate software bill of
> > > materials (SBOM). Java modules do not appear to provide this information
> > > alone, which means any tool that scans a JAR will not get quality
> > > information out of the module metadata.
> > >
> > > On the challenges of trusted checksums (thanks Tamás!):
> > >
> > > 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.
> > >
> > >
> > > This alludes to what John was getting at in his first email on the thread.
> > > The broader ecosystem is not aware of the Trusted Checksums feature and
> > > thus has not adopted it. GitHub's Dependabot would need to implement its
> > > own logic to detect the presence of trusted checksum files and run
> > > appropriate maven commands to get those checksum files updated (is there a
> > > standard/consistent way to do this?). The same would go for other tools
> > > like Renovate, which does not run any post-update commands for Maven [1].
> > >
> > > The last thing I want to add with respect to trusted checksums vs. a
> > > lockfile is that the maven-lockfile we're currently working on provides a
> > > context tree for dependencies. Trusted checksums provide a flat tree of
> > > dependencies that can provide completeness, but additional analysis would
> > > be needed to determine the context of the dependency. Ex: is the
> > > dependency
> > > reachable at runtime? Does it potentially participate in the build
> > > process?
> > > Software teams need this context to determine if a dependency
> > > vulnerability
> > > has real impact and should be patched, or conversely is safe to keep
> > > as-is.
> > >
> > > [1] https://docs.renovatebot.com/configuration-options/#postupdateoptions
> > >
> > > On Wed, Jan 28, 2026 at 7:51 AM Tamás Cservenák <[email protected]>
> > > wrote:
> > >
> > > > 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]
> > > >
> > > >
> > >
> > > --
> > >
> > > 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]
