To clarify, I was envisioning two goals here
Resolution speed: Resolution should improve if lookups can be
short-circuited based on configuration, rather than querying repositories
sequentially until a match is found. With multiple repositories configured,
Maven may perform several unsuccessful lookups before locating an artifact,
which becomes increasingly inefficient in projects with large dependency
graphs. This also causes dependency metadata leaks and while the risk is
low, it is not 0.
Stronger chain of trust: Provide stronger control over where dependencies
are sourced from. As you noted, another approach is to use hash
verification mechanisms such as lock files or PGP signatures. However,
Maven does not provide strict dependency verification or lockfile support
out of the box as far as I know, and stronger integrity or trust
enforcement typically relies on additional configuration, repository
features, or third party plugins[1][2]. I personally feel uneasy depending
on third party plugins due to long term maintainability concerns in
comparison to maven-core.
From a design perspective I was envisioning something along the following
lines:
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-core</artifactId>
<version>3.9.12</version>
<repositoryId>custom-repo-id</repositoryId>
</dependency>
This design breaks for transitive dependencies and probably many other
scenarios, so it is just an starting idea to illustrate what i meant
I believe the Remote Repository Filtering solution[3] addresses the first
problem, but it becomes challenging in scenarios involving parent and child
relationships and reactor builds, where copying these files around is not
ideal. I would prefer a solution that integrates directly with the POM,
providing a single centralized source of truth that can be shared across
projects, without relying on CI workarounds so it also works seamlessly for
local development.
I believe asking users to “create their own repository” or "just build
from source" as a workaround is not a practical solution. In enterprise
environments with thousands of dependencies, this approach does not scale.
Even outside of corporate settings, in the OSS ecosystem, there is a clear
cost–benefit advantage to reducing unnecessary dependency resolution
calls[4]
Perhaps the much better solution is to use dependency verification for
trust concerns, but I think that the resolution speed concern is still
valid.
Also, to clarify, this is currently just a question to hear your thoughts
and hear how you normally solve this at scale. I understand that this is
probably a large/breaking change
[1] https://github.com/s4u/pgpverify-maven-plugin
[2] https://github.com/chains-project/maven-lockfile
[3] https://maven.apache.org/resolver/remote-repository-filtering.html
[4]
https://docs.gradle.org/current/userguide/best_practices_dependencies.html#use_content_filtering
Thanks!
From: Romain Manni-Bucau <[email protected]>
To: "Maven Developers List"<[email protected]>
Cc: "Maven Users List"<[email protected]>
Date: Wed, 11 Feb 2026 09:45:48 -0500
Subject: Re: Per-dependency repository resolution in Maven?
hi
did you try
https://maven.apache.org/resolver/remote-repository-filtering.html ?
Romain Manni-Bucau
@rmannibucau < https://x.com/rmannibucau > | .NET Blog
< https://dotnetbirdie.github.io/ > | Blog <
https://rmannibucau.github.io/ > | Old
Blog < http://rmannibucau.wordpress.com > | Github
< https://github.com/rmannibucau > | LinkedIn
< https://www.linkedin.com/in/rmannibucau > | Book
<
https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
Javaccino founder (Java/.NET service - contact via linkedin)
Le mer. 11 févr. 2026 à 15:39, Elliotte Rusty Harold < mailto:
[email protected] > a
Ă©crit :
On Wed, Feb 11, 2026 at 2:22 PM Richard Gomez < mailto:
[email protected] >
wrote:
This is a common use case in enterprise software: there's a billion
dollar
industry of solutions that resolve certain groupIds/artifactIds
against
specific repositories to avoid supply-chain attacks (e.g., dependency
confusion).
Yes, that is the obvious use case. If it's a practical use case at
that scale, then I would expect one or more enterprises to be willing
to devote on the order of a few million dollars in money and/or full
time employees to the task.
This one isn't going to be easy. It's not something that can be done
in a single PR, and might not be possible without breaking backwards
compatibility.
I'm also not yet convinced this is needed or the correct solution to
the supply chain problem. If someone came to me today with this
concern, I'd tell them to set up their own local repository where they
could control everything and possibly build every binary from source.
Companies do this today. Locking in a specific remote repository
doesn't really prevent supply chain attacks when that repository is
compromised. Reproducible builds, signed binaries, SSL connections,
and single version dependencies are more effective and much cheaper
ways of addressing supply chain problems. I can think of at least two
attacks* that can bypass those, but those attacks would also bypass
per-dependency repository resolution.
* Taking control of the remote repository and taking control of the
local developer machine or build server.
--
Elliotte Rusty Harold
mailto:[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: mailto:[email protected]
For additional commands, e-mail: mailto:[email protected]
