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

["Konrad Windszus (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MENFORCER-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Konrad Windszus reassigned MENFORCER-467:
-----------------------------------------

    Assignee: Konrad Windszus

> 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: banDynamicVersions, Standard Rules
>    Affects Versions: 3.2.1
>            Reporter: Stephan Schroevers
>            Assignee: Konrad Windszus
>            Priority: Major
>             Fix For: 3.3.0
>
>
> 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)