[
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: "should be 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 remote
repository (100% reliable)
* in resolution, preventing locally *cached* 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 will fail to filter, while EnhancedLRM does
track it and will work as expected).
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.
Filters implemented in this round:
* groupId - provide a list of groupIds per remote repository
* prefix - use prefixes file for allowed prefixes (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: "should be 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 remote
repository (100% reliable)
* in resolution, preventing locally *cached* 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 will fail to filter, while EnhancedLRM does
track it and will work as expected).
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...
> 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: "should be 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 remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* 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 will fail to filter, while
> EnhancedLRM does track it and will work as expected).
> 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.
> Filters implemented in this round:
> * groupId - provide a list of groupIds per remote repository
> * prefix - use prefixes file for allowed prefixes (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)
