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 <[email protected]> a écrit : > On Wed, Feb 11, 2026 at 2:22 PM Richard Gomez <[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 > [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
