[
https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17282914#comment-17282914
]
Tamás Cservenák edited comment on MNG-7097 at 2/11/21, 8:11 AM:
----------------------------------------------------------------
FTR, the "experiments" mentioned above is this:
Setup:
- am using (primed) MRM, not interested in bashing Central or measuring my ISP
network speed
- am always nuking local repo (hence, starting state is "get everything needed
for build")
- my test bed project is maven itself (master,
ab20190a1a9fecdc8f85b40e8d03d806f3da4fc6)
- build + tests ARE executed, and succeed OK, but I was really interested in
local repository post-build state
- command line am executing from maven checkout root is: {{rm -r /tmp/repo;
~/bin/maven/apache-maven-XXX/bin/mvn clean install
-Dmaven.repo.local=/tmp/repo}}
results with mvn master (4.0.0-alpha-1,
ab20190a1a9fecdc8f85b40e8d03d806f3da4fc6):
total time 1:08 min (as Maven reports)
total files in local repo: 3741
total bytes in local repo: 162428
count of files having "plexus-container-default" in local repo: 37 (18 POM,
10 JAR)
Patch
[https://github.com/apache/maven/compare/master...cstamas:plugin-resolution-hack]
results with above patched mvn master:
total time 1:04 min (as Maven reports)
total files in local repo: 2992
total bytes in local repo: 149740
count of files having "plexus-container-default" in local repo: 0
was (Author: cstamas):
FTR, the "experiments" mentioned above is this:
Setup:
- am using (primed) MRM, not interested in bashing Central or measuring my ISP
network speed
- am always nuking local repo (hence, starting state is "get everything needed
for build")
- my test bed project is maven itself (master,
ab20190a1a9fecdc8f85b40e8d03d806f3da4fc6)
- build + tests ARE executed, and succeed OK, but I was really interested in
local repository post-build state
- command line am executing from maven checkout root is: {{rm -r /tmp/repo;
~/bin/maven/apache-maven-XXX/bin/mvn clean install
-Dmaven.repo.local=/tmp/repo}}
mvn master (4.0.0-alpha-1, ab20190a1a9fecdc8f85b40e8d03d806f3da4fc6):
total time 1:08 min (as Maven reports)
total files in local repo: 3741
total bytes in local repo: 162428
count of files having "plexus-container-default" in local repo: 37 (18 POM, 10
JAR)
Patch
[https://github.com/apache/maven/compare/master...cstamas:plugin-resolution-hack]
results with above patched mvn master:
total time 1:04 min (as Maven reports)
total files in local repo: 2992
total bytes in local repo: 149740
count of files having "plexus-container-default" in local repo: 0
> Plugin Dependency Resolution
> ----------------------------
>
> Key: MNG-7097
> URL: https://issues.apache.org/jira/browse/MNG-7097
> Project: Maven
> Issue Type: Task
> Components: Performance, Plugins and Lifecycle
> Reporter: Tamás Cservenák
> Priority: Major
>
> Current Maven behavior for resolving plugin dependencies is to download full
> transitive graph of plugin dependency, but for executing plugin it filters
> out core artifacts from graph (excludes them).
> This results in unnecessary downloads of core artifacts, multiplied by
> multiple versions used by different plugins, and local repository end up
> having artifacts that may even surprise users.
> Most notable examples: maven-core (user: "Why did Maven download maven-core-X
> when I use maven-Y?"), plexus-container-default (user: "Why does Maven
> download 10+ versions of this legacy artifact (adv user: when
> sisu-inject-plexus shim is used instead)?"), multiple versions of
> plexus-utils etc...
> We need to investigate what exactly happens with downloaded, but unused core
> artifacts (if they are completely excluded based on GAV, we are safest), and
> simply exclude them even from resolution/collection, as they are really not
> needed.
> This will not "improve build speed", but does lessen "bandwidth", as
> experiments shows that cutting plugin dependencies for core artifacts for
> Maven project itself makes about 1k less remote requests (artifact and
> artifact checksum downloads).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
