Forgot one important detail: this demo above is for maven 3.8.x vs 3.9.x In Maven 4 (that uses Resolver 2.x) the group filter is heavily improved: https://maven.apache.org/resolver/remote-repository-filtering.html
Expressions like `!org.foo` EXCLUDES. For similar capability with Maven 3, one can use: https://github.com/maveniverse/heimdall On Wed, Feb 11, 2026 at 6:05 PM Tamás Cservenák <[email protected]> wrote: > > 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]
