[jira] [Created] (MENFORCER-467) Problematic dependency resolution by new `banDynamicVersions` rule

["Stephan Schroevers (Jira)" <ji...@apache.org>]

Stephan Schroevers created MENFORCER-467:
--------------------------------------------

             Summary: Problematic dependency resolution by new `banDynamicVersions` rule
                 Key: MENFORCER-467
                 URL: https://issues.apache.org/jira/browse/MENFORCER-467
             Project: Maven Enforcer Plugin
          Issue Type: Bug
          Components: Standard Rules
    Affects Versions: 3.2.1
            Reporter: Stephan Schroevers


The new [banDynamicVersions|https://maven.apache.org/enforcer/enforcer-rules/banDynamicVersions.html] rule seems in _too_ aggressive its dependency resolution, leading to:
# _Very many_ additional {{pom}} files being resolved.
# The downloading of (IIUC) test dependencies of third-party dependencies.
# Attempts to resolve artifacts from a wide variety of repositories, including ones that are not configured for the main reactor build and ones that are unreachable thanks to the {{maven-default-http-blocker}}.
# A near-certain build failure, because any non-trivial Maven project is very likely to pull in a dependency which "leads to" an inaccessible repository. 

To observe the issue, consider running the following reproduction steps:

{code:sh}
git clone git@github.com:PicnicSupermarket/error-prone-support.git
cd error-prone-support
git checkout a55ed9cea9aef6ae04ed78237612aa9ca008b06a

# First, perform a regular build using an empty local Maven repository.
mvn clean package -s settings.xml -DskipTests -Dmaven.repo.local=repo-before | tee output-before.log

# Then, additionally enable `banDynamicVersions`.
sed -i '/<banDuplicatePomDependencyVersions \/>/a\                            <banDynamicVersions \/>' pom.xml

# Finally, perform a second build using yet another local Maven repository,
# populated with the artifacts collected during the first build.
cp -rp repo-before repo-after
mvn clean package -s settings.xml -DskipTests -Dmaven.repo.local=repo-after | tee output-after.log
{code}

Observe that:
# The second build fails due to a resolution error (more on that below).
# The second build caused the local repository to grow by 80 MB:
    {code}
    $ du -hs repo-before repo-after
    114M    repo-before
    194M    repo-after{code}
    Note that this is 80 megabyte of just {{pom}} files, hash files and repository meta-data.
# There was an attempt to resolve what appears to be unrelated test dependencies. Grep {{output-after.log}} for {{junit}}, {{testng}}, {{selenium}}, {{truth}} etc. to see what I mean:
    {code}
    $ grep 'Downloading from central' output-after.log | grep -oP '/(junit|selenium|testng|truth)/' | sort | uniq -c
         19 /junit/
         76 /selenium/
          3 /testng/
         11 /truth/{code}
# There were many attempts to contact repositories that were only mentioned indirectly:
    {code}
    $ grep -oP 'Downloading from [^:]+' output-after.log  | sort | uniq -c
         22 Downloading from apache.snapshots
         12 Downloading from apache.snapshots.https
       3635 Downloading from central
         12 Downloading from maven-default-http-blocker
          1 Downloading from openjpa-internal
          7 Downloading from sonatype-google-snapshots
         15 Downloading from sonatype-nexus-snapshots
          2 Downloading from sonatype-snapshots{code}

The resolution error that failed the build was due to the {{maven-default-http-blocker}} rewrite, but presumably, if any of the dependencies would have referenced another now-defunct HTTPS repository, then that would also have caused a failure.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)