[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614450#comment-17614450
]
ASF GitHub Bot commented on MRESOLVER-274:
------------------------------------------
cstamas commented on PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#issuecomment-1272276273
> General question: Is it intended to plugin with Maven repo definition in
POM and settings to have nested elements `<includes />`/`<excludes />`? Similar
to maven-common-artifact-filters. This would be easily accessible, but requires
model changes and would work without any brainfuck for the users.
https://issues.apache.org/jira/browse/MNG-6763
This is maven-resolver, not maven. Hence, one can consier this as
"foundation" (low level) implementation, that can be topped in many different
ways, for example, Maven could either provide it's own filter implementations
sourced from new model (if model is changed to support that) or just "manage"
these "low level" sources in some way. This PR is not related in any way to
Maven, as it have no access to models like POM, Settings, etc. It just lies
down the foundations to solve that issue.
> 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: Tamas Cservenak
> Assignee: Tamas Cservenak
> 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)
