Re: Per-dependency repository resolution in Maven?

2026-02-11 Thread Tamás Cservenák 
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  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:
>
>
>
> 
>
> org.apache.maven
>
> maven-core
>
> 3.9.12
>
> custom-repo-id
>
> 
>
>
> 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 
> To: "Maven Developers List"
> Cc: "Maven Users List"
> 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:
> >

Re: Per-dependency repository resolution in Maven?

2026-02-11 Thread 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  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:
>
>
>
> 
>
> org.apache.maven
>
> maven-core
>
> 3.9.12
>
> custom-repo-id
>
> 
>
>
> 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 
> To: "Maven Developers List"
> Cc: "Maven Users List"
> 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

Re: Per-dependency repository resolution in Maven?

2026-02-11 Thread Yeikel Santana 
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:





    org.apache.maven

    maven-core

    3.9.12

    custom-repo-id




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 
To: "Maven Developers List"
Cc: "Maven Users List"
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

Re: Per-dependency repository resolution in Maven?

2026-02-11 Thread Romain Manni-Bucau 
hi

did you try
https://maven.apache.org/resolver/remote-repository-filtering.html ?

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book

Javaccino founder (Java/.NET service - contact via linkedin)


Le mer. 11 févr. 2026 à 15:39, Elliotte Rusty Harold  a
écrit :

> On Wed, Feb 11, 2026 at 2:22 PM Richard Gomez 
> 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
> [email protected]
>
> -
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Re: Per-dependency repository resolution in Maven?

2026-02-11 Thread Mantas Gridinas 
Im confused still. Why doesn't remote repository filtering (available since
maven 3.9) does not fit here?

On Wed, Feb 11, 2026, 16:22 Richard Gomez  wrote:

> > I can certainly see a use case for that. OTOH it would be very complex,
> and if no one's asked for it before now maybe it doesn't actually solve a
> significant real world problem?
>
> 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).
>
> I would love to have first-class support for repository-specific
> dependencies in pom.xml, similar to Gemfile (
> https://bundler.io/man/gemfile.5.html#SOURCE)
>
> On Wed, Feb 11, 2026 at 9:15 AM Elliotte Rusty Harold 
> wrote:
>
> > On Wed, Feb 11, 2026 at 1:27 PM Yeikel Santana  wrote:
> > >
> > > Currently, Maven resolves artifacts from repositories in order and does
> > not allow specifying a repository per dependency.
> > >
> > >
> > > In scenarios where the same artifact coordinates may exist in multiple
> > repositories, there does not appear to be a built-in way to enforce that
> a
> > specific dependency be resolved only from a specific repository.
> > >
> > >
> > > Has per-dependency repository resolution ever been discussed or
> > considered in Maven’s design? Not as a default but as a feature that
> could
> > be enabled
> > >
> >
> > I can certainly see a use case for that. OTOH it would be very
> > complex, and if no one's asked for it before now maybe it doesn't
> > actually solve a significant real world problem? I also worry that it
> > might cut against Maven's design and architecture. Currently there's a
> > pretty deep assumption baked into Maven that a GAV uniquely identifies
> > an artifact no matter which repository it happens to come from. This
> > is important for local mirrors and similar infrastructure.
> >
> > I don't expect this would be a feature that could be enabled. If it
> > were done at all, it would likely be an extra element in pom.xml that
> > Maven 4.x and later would simply recognize if present.
> >
> > --
> > Elliotte Rusty Harold
> > [email protected]
> >
> > -
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>


// Mantas

Re: Per-dependency repository resolution in Maven?

2026-02-11 Thread Elliotte Rusty Harold 
On Wed, Feb 11, 2026 at 2:22 PM Richard Gomez  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
[email protected]

-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Re: Per-dependency repository resolution in Maven?

2026-02-11 Thread Richard Gomez 
> I can certainly see a use case for that. OTOH it would be very complex,
and if no one's asked for it before now maybe it doesn't actually solve a
significant real world problem?

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).

I would love to have first-class support for repository-specific
dependencies in pom.xml, similar to Gemfile (
https://bundler.io/man/gemfile.5.html#SOURCE)

On Wed, Feb 11, 2026 at 9:15 AM Elliotte Rusty Harold 
wrote:

> On Wed, Feb 11, 2026 at 1:27 PM Yeikel Santana  wrote:
> >
> > Currently, Maven resolves artifacts from repositories in order and does
> not allow specifying a repository per dependency.
> >
> >
> > In scenarios where the same artifact coordinates may exist in multiple
> repositories, there does not appear to be a built-in way to enforce that a
> specific dependency be resolved only from a specific repository.
> >
> >
> > Has per-dependency repository resolution ever been discussed or
> considered in Maven’s design? Not as a default but as a feature that could
> be enabled
> >
>
> I can certainly see a use case for that. OTOH it would be very
> complex, and if no one's asked for it before now maybe it doesn't
> actually solve a significant real world problem? I also worry that it
> might cut against Maven's design and architecture. Currently there's a
> pretty deep assumption baked into Maven that a GAV uniquely identifies
> an artifact no matter which repository it happens to come from. This
> is important for local mirrors and similar infrastructure.
>
> I don't expect this would be a feature that could be enabled. If it
> were done at all, it would likely be an extra element in pom.xml that
> Maven 4.x and later would simply recognize if present.
>
> --
> Elliotte Rusty Harold
> [email protected]
>
> -
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Re: Per-dependency repository resolution in Maven?

2026-02-11 Thread Elliotte Rusty Harold 
On Wed, Feb 11, 2026 at 1:27 PM Yeikel Santana  wrote:
>
> Currently, Maven resolves artifacts from repositories in order and does not 
> allow specifying a repository per dependency.
>
>
> In scenarios where the same artifact coordinates may exist in multiple 
> repositories, there does not appear to be a built-in way to enforce that a 
> specific dependency be resolved only from a specific repository.
>
>
> Has per-dependency repository resolution ever been discussed or considered in 
> Maven’s design? Not as a default but as a feature that could be enabled
>

I can certainly see a use case for that. OTOH it would be very
complex, and if no one's asked for it before now maybe it doesn't
actually solve a significant real world problem? I also worry that it
might cut against Maven's design and architecture. Currently there's a
pretty deep assumption baked into Maven that a GAV uniquely identifies
an artifact no matter which repository it happens to come from. This
is important for local mirrors and similar infrastructure.

I don't expect this would be a feature that could be enabled. If it
were done at all, it would likely be an extra element in pom.xml that
Maven 4.x and later would simply recognize if present.

-- 
Elliotte Rusty Harold
[email protected]

-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Re: Per-dependency repository resolution in Maven?

2026-02-11 Thread Gary Gregory 
I would use such a feature (at work)!

Gary

On Wed, Feb 11, 2026, 08:26 Yeikel Santana  wrote:

> Currently, Maven resolves artifacts from repositories in order and does
> not allow specifying a repository per dependency.
>
>
> In scenarios where the same artifact coordinates may exist in multiple
> repositories, there does not appear to be a built-in way to enforce that a
> specific dependency be resolved only from a specific repository.
>
>
> Has per-dependency repository resolution ever been discussed or considered
> in Maven’s design? Not as a default but as a feature that could be enabled
>
>
> The goal would be to enforce that certain artifacts (for example, internal
> coordinates) must only be resolved from a designated repository, and that
> the build should fail if they are resolved from any other repository even
> if the artifact exists in multiple registries.
>
>
> In Gradle, in case it matters, this is done via "includeGroup" [1]
>
>
>
> https://docs.gradle.org/current/kotlin-dsl/gradle/org.gradle.api.artifacts.repositories/-inclusive-repository-content-descriptor/include-group.html
>
>
> Thanks

Re: Per-dependency repository resolution in Maven?

2026-02-11 Thread Mantas Gridinas 
Does remote repository filtering fit your usecase?
https://maven.apache.org/resolver/remote-repository-filtering.html


// Mantas

On Wed, Feb 11, 2026, 15:27 Yeikel Santana  wrote:

> Currently, Maven resolves artifacts from repositories in order and does
> not allow specifying a repository per dependency.
>
>
> In scenarios where the same artifact coordinates may exist in multiple
> repositories, there does not appear to be a built-in way to enforce that a
> specific dependency be resolved only from a specific repository.
>
>
> Has per-dependency repository resolution ever been discussed or considered
> in Maven’s design? Not as a default but as a feature that could be enabled
>
>
> The goal would be to enforce that certain artifacts (for example, internal
> coordinates) must only be resolved from a designated repository, and that
> the build should fail if they are resolved from any other repository even
> if the artifact exists in multiple registries.
>
>
> In Gradle, in case it matters, this is done via "includeGroup" [1]
>
>
>
> https://docs.gradle.org/current/kotlin-dsl/gradle/org.gradle.api.artifacts.repositories/-inclusive-repository-content-descriptor/include-group.html
>
>
> Thanks