Did you try the client side routing? this solves that 🤔 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 à 17:33, Yeikel Santana <[email protected]> a écrit : > 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] > > > >
