[
https://issues.apache.org/jira/browse/MENFORCER-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned MENFORCER-467:
---------------------------------------------
Assignee: Slawomir Jaranowski (was: 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: Slawomir Jaranowski
> 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 g...@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)
