[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623892#comment-17623892
]
ASF GitHub Bot commented on MRESOLVER-274:
------------------------------------------
gnodet commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r1004603781
##########
src/site/markdown/remote-repository-filtering.md:
##########
@@ -0,0 +1,166 @@
+# Remote Repository Filtering
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+A new Maven Resolver feature that allows filtering of Artifact by
RemoteRepository based on various (extensible)
+criteria.
+
+### Why?
+
+Remote Repository Filtering (RRF) is a long asked feature of Maven, and plays
huge role when your build uses
+several remote repositories. In such cases Maven "searches" the ordered list
(effective POM) of remote repositories,
+and artifact gets resolved using loop and "first found wins" strategy. This
have several implications:
+
+* your build gets slower, as if your artifact is in Nth repository, Maven must
make N-1 requests that will result in
Review Comment:
`in Nth` -> `in the Nth`
##########
src/site/markdown/remote-repository-filtering.md:
##########
@@ -0,0 +1,166 @@
+# Remote Repository Filtering
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+A new Maven Resolver feature that allows filtering of Artifact by
RemoteRepository based on various (extensible)
+criteria.
+
+### Why?
+
+Remote Repository Filtering (RRF) is a long asked feature of Maven, and plays
huge role when your build uses
Review Comment:
`plays huge` -> `plays a huge`
##########
src/site/markdown/remote-repository-filtering.md:
##########
@@ -0,0 +1,166 @@
+# Remote Repository Filtering
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+A new Maven Resolver feature that allows filtering of Artifact by
RemoteRepository based on various (extensible)
+criteria.
+
+### Why?
+
+Remote Repository Filtering (RRF) is a long asked feature of Maven, and plays
huge role when your build uses
+several remote repositories. In such cases Maven "searches" the ordered list
(effective POM) of remote repositories,
+and artifact gets resolved using loop and "first found wins" strategy. This
have several implications:
Review Comment:
`artifact gets` -> `artifacts get`
`using loop and "first` -> `using a loop a "first`
`This have` -> `This has`
##########
src/site/markdown/remote-repository-filtering.md:
##########
@@ -0,0 +1,166 @@
+# Remote Repository Filtering
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+A new Maven Resolver feature that allows filtering of Artifact by
RemoteRepository based on various (extensible)
+criteria.
+
+### Why?
+
+Remote Repository Filtering (RRF) is a long asked feature of Maven, and plays
huge role when your build uses
+several remote repositories. In such cases Maven "searches" the ordered list
(effective POM) of remote repositories,
+and artifact gets resolved using loop and "first found wins" strategy. This
have several implications:
+
+* your build gets slower, as if your artifact is in Nth repository, Maven must
make N-1 requests that will result in
+ 404 Not Found only to get to Nth repository to finally get the artifact.
+* you build "leaks" artifact requests, as those repositories are asked for
artifacts, that does not (or worse,
+ cannot) have them. Still, those remote repository operators do get your
requests in access logs.
+* to "simplify" things, users tend to use MRM "group" (or "virtual")
repositories, that causes data loss on
+ Maven Project side (project loses artifact origin information) and ends up
in disasters, as at the end these
+ "super-uber groups" grow uncontrollably, their member count become huge (as
new members are being
+ added as time passes), or created groups count grows uncontrollably, and
project start losing the knowledge
+ about their required remote repositories, needed to (re)build a project,
hence these projects become
+ un-buildable without the MRM, projects become bound to MRM and/or
environment that is usually out of project
+ control.
+
+Maven by default gets slower as remote repositories are added, leaks your own
build information to remote
+repository operators, and current solutions offered to solve this problem just
end up in disasters (most often).
+
+### What It Is?
+
+Imagine you can instruct Maven which repository can contain what artifact?
Instead of "ordered loop" searching
+for artifacts in remote repositories, Maven could be instructed in controlled
way to directly reach only the
+needed remote repository.
+
+With RRF, Maven build does NOT have to slow down with new remote repositories
added, and will not leak either
+build information anywhere, as it will get things from where they should be
get from.
+
+### What It Is Not?
+
+When it solely comes to dependencies, don't forget
+[maven-enforcer-plugin](https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html)
rules that are
+handling exactly them. RRF is NOT an alternative means to these enforcer
rules, it is a tool to make your build
+faster and more private, optimized, without loosing build information (remote
repositories should be in POM).
+
+### Maven Central Is Special
+
+Maven Central (MC) repository is special in this respect, as Maven will always
try to get things from here, as your build,
+plugins, plugin dependencies, extension, etc. will most often come from here.
While you CAN filter MC, filtering MC is
+most often a bad idea (filtering, as in "limiting what can come from it"). On
other hand, MC itself offers help
+to prevent request leakage to it (see "prefixes" filter).
+
+So, **most often** limiting "what can be fetched" from MC is a bad idea, it
**can be done** but in very, very cautious way,
+as otherwise you put your build at risk. RRF does not distinguish the
"context" of an artifact, it merely filters them out
+by (artifact, remoteRepository) pair, and by limiting MC you can easily get
into state where you break your build (as
+plugin depends on filtered artifact).
+
+## RRF
+
+The RRF feature offer filter source SPI for 3rd party implementors, but it
also provides 2 out of the box
Review Comment:
`offer filter source SPI` -> `offers a filter source SPI`
##########
src/site/markdown/remote-repository-filtering.md:
##########
@@ -0,0 +1,166 @@
+# Remote Repository Filtering
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+A new Maven Resolver feature that allows filtering of Artifact by
RemoteRepository based on various (extensible)
+criteria.
+
+### Why?
+
+Remote Repository Filtering (RRF) is a long asked feature of Maven, and plays
huge role when your build uses
+several remote repositories. In such cases Maven "searches" the ordered list
(effective POM) of remote repositories,
+and artifact gets resolved using loop and "first found wins" strategy. This
have several implications:
+
+* your build gets slower, as if your artifact is in Nth repository, Maven must
make N-1 requests that will result in
+ 404 Not Found only to get to Nth repository to finally get the artifact.
+* you build "leaks" artifact requests, as those repositories are asked for
artifacts, that does not (or worse,
+ cannot) have them. Still, those remote repository operators do get your
requests in access logs.
+* to "simplify" things, users tend to use MRM "group" (or "virtual")
repositories, that causes data loss on
+ Maven Project side (project loses artifact origin information) and ends up
in disasters, as at the end these
+ "super-uber groups" grow uncontrollably, their member count become huge (as
new members are being
+ added as time passes), or created groups count grows uncontrollably, and
project start losing the knowledge
+ about their required remote repositories, needed to (re)build a project,
hence these projects become
+ un-buildable without the MRM, projects become bound to MRM and/or
environment that is usually out of project
+ control.
+
+Maven by default gets slower as remote repositories are added, leaks your own
build information to remote
+repository operators, and current solutions offered to solve this problem just
end up in disasters (most often).
+
+### What It Is?
+
+Imagine you can instruct Maven which repository can contain what artifact?
Instead of "ordered loop" searching
+for artifacts in remote repositories, Maven could be instructed in controlled
way to directly reach only the
+needed remote repository.
+
+With RRF, Maven build does NOT have to slow down with new remote repositories
added, and will not leak either
+build information anywhere, as it will get things from where they should be
get from.
+
+### What It Is Not?
+
+When it solely comes to dependencies, don't forget
+[maven-enforcer-plugin](https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html)
rules that are
+handling exactly them. RRF is NOT an alternative means to these enforcer
rules, it is a tool to make your build
+faster and more private, optimized, without loosing build information (remote
repositories should be in POM).
+
+### Maven Central Is Special
+
+Maven Central (MC) repository is special in this respect, as Maven will always
try to get things from here, as your build,
+plugins, plugin dependencies, extension, etc. will most often come from here.
While you CAN filter MC, filtering MC is
+most often a bad idea (filtering, as in "limiting what can come from it"). On
other hand, MC itself offers help
+to prevent request leakage to it (see "prefixes" filter).
+
+So, **most often** limiting "what can be fetched" from MC is a bad idea, it
**can be done** but in very, very cautious way,
+as otherwise you put your build at risk. RRF does not distinguish the
"context" of an artifact, it merely filters them out
+by (artifact, remoteRepository) pair, and by limiting MC you can easily get
into state where you break your build (as
+plugin depends on filtered artifact).
+
+## RRF
+
+The RRF feature offer filter source SPI for 3rd party implementors, but it
also provides 2 out of the box
+implementations for filtering: "prefixes" and "groupId" filters.
+
+Both implementation operate with several files (per remote repository), and
they use the term "filter basedir". By
+default, filter basedir is resolved from local repository root and resolves to
`${localRepo}/.remoteRepositoryFilters`
+directory, and will refer to it in this document with `${filterBasedir}`
placeholder.
Review Comment:
`directory, and will refer to it in` -> `directory. It will be referred to
in`
> Introduce Remote Repository Filter feature
> ------------------------------------------
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 1.9.0
>
>
> 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)
