Think there are multiple topics but overall the feature is there and doesn't have to be implemented. Now what "view" do we want to expose is another topic but I think we shouldn't miss the fact it is not about repository-artifact link but more generally about resolver configuration within the pom. Personally I think the mapping of artifact to a repository is wrong in the pom cause as soon as you become transitive you just want to not respect it anymore so maybe a resolver section or alike (thinking out loud).
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:48, Christoph Läubrich <[email protected]> a écrit : > Repository filtering is just to cumbersome to use and easily to break as > it is pure *client* configuration. > > Having a dependency specify its repository would also help custom > repository implementations like Tycho, currently we use a quite ugly > hack to start the group.id with p2.<realgroupid> other use serverid as > group ID (e.g. P2 transport extension). > > Having it properly encoded in the pom makes it easy to copy, the same > GAV might come from different servers even on the same system and then > one has to replicate configuration per project. > > Am 11.02.26 um 17:34 schrieb Romain Manni-Bucau: > > 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] > >>> > >>> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
