[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-274:
--------------------------------------
Description:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "is Artifact available from
RemoteRepository?" and is able to employ several combination (via consensus, or
later possibly other strategies) of several "filter sources" that are
extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from (100% reliable)
* in resolution, preventing locally present artifact to be resolved (reliable
as much as your local repository is clean, ie. if you used Simple LRM on it, it
does not track remote origins, while EnhancedLRM does track it).
By default this feature is "dormant" (resolver behaves exactly same as before
without it). This is intended as "low level" feature that later can be built
upon, and implement some more user friendly solutions like MNG-6763. Hence,
this issue and resolver code changes are NOT meant to completely implement
MNG-6763, but more like to provide needed (lower level) functionalities to make
it possible.
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
was:
The feature, as it's name says should be able to "filter" RemoteRepositories by
some criteria ("known bad GAVs", "allowed groupId", etc).
In short, this feature allows following filtering: "is Artifact available from
RemoteRepository?" and is able to employ several combination (via consensus, or
later possibly other strategies) of several "filter sources" that are
extensible (via adding new components).
Filter is used in two places:
* in connector, preventing remote artifact to be fetched from (100% reliable)
* in resolution, preventing locally present artifact to be resolved (reliable
as much as your local repository is clean, ie. if you used Simple LRM on it, it
does not track remote origins, while EnhancedLRM does track it).
Examples:
* provide a list of groupIds (this is done by demo)
* use prefixes file (example central
[https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
[https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
* maybe package up an artifact holding list of "known" bad artifacts and
consume that (and enforce it)
* etc...
> Introduce Remote Repository Filter feature
> ------------------------------------------
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
> Reporter: Tamás Cservenák
> Assignee: Tamás Cservenák
> Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "is Artifact available
> from RemoteRepository?" and is able to employ several combination (via
> consensus, or later possibly other strategies) of several "filter sources"
> that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from (100% reliable)
> * in resolution, preventing locally present artifact to be resolved
> (reliable as much as your local repository is clean, ie. if you used Simple
> LRM on it, it does not track remote origins, while EnhancedLRM does track it).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Examples:
> * provide a list of groupIds (this is done by demo)
> * use prefixes file (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
