[ 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)