Howdy, See https://github.com/cstamas/rrf-demo
re speed: as docs the build time (always w/ empty repo) went from original 2:28 to 0:20. re supply chain security: post RRF the artifacts were coming from where they should come (central) and not via atlassian supergroup Related writeups: https://maveniverse.eu/blog/2025/11/09/why-are-mrm-group-repositories-bad/ and somewhat https://maveniverse.eu/blog/2025/06/12/mimir-and-rrf/ and others. Thanks T On Wed, Feb 11, 2026 at 5:33 PM Yeikel Santana <[email protected]> wrote: > > 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]
