[Commented] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[Commented] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts

Tibor Digana (Jira)

    [ https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288583#comment-17288583 ]

Tamás Cservenák commented on MNG-7097:

So, it seems this PR as is, will not work with cases like described in MNG-5783 (plugin spawns separate JVM with class path), as class path with this kind of filtering (as this PR introduces) will be "incomplete", it will be "complete" ONLY within Maven, but never complete outside of Maven (to spawn a JVM for example). So, several ideas:
 * make possible to "tweak" plugin resolution by something (per plugin): config? I bet in 99% of cases this PR is fine, but the 1% may need some workaround, but being able to make plugin "resolve" FULL (instead of "filtered")
 * "fake" resolution of artifacts present in core: collect them, but Artifact should point to Maven lib? This is dangerous, as plugin would have access to Files comprising Maven, also we lack _versions_, currently we have GA only (in CoreExports).
 * Leave all as is (drop PR)? I think this is huge "overall penalty", only to support some (how many?) plugins using {{$\{plugin.artifacts}}} to do these kinds of stuff... 

> Plugin Dependency Resolution: don't download Maven-provided artifacts
> ---------------------------------------------------------------------
>                 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
>            Assignee: 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