You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Łukasz Dywicki (Jira)" <ji...@apache.org> on 2022/06/07 11:21:00 UTC
[jira] [Updated] (MRESOLVER-263) Resolver side routing and filtering capability
[ https://issues.apache.org/jira/browse/MRESOLVER-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Łukasz Dywicki updated MRESOLVER-263:
-------------------------------------
Description:
Maven resolver is fine tool when it comes to playing with mirroring of repositories. Yet it has few points which drastically lower its performance.
Given an example of project with two mirrored repositories:
{{repoA-mirror -> repoA -> central}}
{{repoB-mirror -> central}}
Resolver will attempt to fetch metadata from repoA mirror and repoB mirror even if its not feasible. Currently there is no way to tell resolver that given mirror is bound to subset of artifacts as routing and filtering capabilities on that end are very short. It happens that mirrored repository contains specific releases but also central entries.
All this leads to situations that same metadata is requested several times. Problem increases with more repositories as each of them can be queried. This obviously multiplies network traffic which could be spent somewhere else.
I don't really have an idea how this could be solved. I am just aware of existence of that issue. At the same time I do not wish to utilize specific products which work as a repository proxy. They are a workaround for this resolver issue.
was:
Maven resolver is fine tool when it comes to playing with mirroring of repositories. Yet it has few points which drastically lower its performance.
Given an example of project with two mirrored repositories:
{{repoA-mirror -> repoA -> central}}
{{repoB-mirror -> central}}
Resolver will attempt to fetch metadata from repoA mirror and repoB mirror even if its not feasible. Currently there is no way to tell resolver that given mirror is bound to subset of artifacts as routing and filtering capabilities on that end are very short. It happens that mirrored repository contains specific releases but also central entries.
All this leads to situations that same metadata is requested several times. Problem increases with more repositories as each of them can be queried. This obviously multiplies network traffic which could be spent somewhere else.
I don't really have an idea how this could be solved. I am just aware of existence of that issue. At the same time I do not wish to utilize specific products which work as a repository proxy. They are a workaround of resolver issue.
> Resolver side routing and filtering capability
> ----------------------------------------------
>
> Key: MRESOLVER-263
> URL: https://issues.apache.org/jira/browse/MRESOLVER-263
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
> Affects Versions: 1.8.0
> Reporter: Łukasz Dywicki
> Priority: Major
>
> Maven resolver is fine tool when it comes to playing with mirroring of repositories. Yet it has few points which drastically lower its performance.
> Given an example of project with two mirrored repositories:
> {{repoA-mirror -> repoA -> central}}
> {{repoB-mirror -> central}}
> Resolver will attempt to fetch metadata from repoA mirror and repoB mirror even if its not feasible. Currently there is no way to tell resolver that given mirror is bound to subset of artifacts as routing and filtering capabilities on that end are very short. It happens that mirrored repository contains specific releases but also central entries.
> All this leads to situations that same metadata is requested several times. Problem increases with more repositories as each of them can be queried. This obviously multiplies network traffic which could be spent somewhere else.
> I don't really have an idea how this could be solved. I am just aware of existence of that issue. At the same time I do not wish to utilize specific products which work as a repository proxy. They are a workaround for this resolver issue.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)