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] > >
