What about mapping artifact to repository in the lock file, as done in yarn.lock? Delany
On Wed, 11 Feb 2026, 18:57 Romain Manni-Bucau, <[email protected]> wrote: > 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] > > > > >
