lock file locking happens after resolution so means you used RRF or alike before == it can persist it for future but not provide the info upfront or it is not the right place to configure it since these files are not written manually (same for npm/yarn/bun & friends).
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 à 22:03, Delany <[email protected]> a écrit : > 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] > > > > > > > > >
