Thanks for PR.
I will check it, but afraid that we should filter artifacts by scope before resolving/collecting it.

dependency:tree has a bug for such cases https://issues.apache.org/jira/browse/MDEP-909

@cstamas please also look

I will check it, but afraid that we should filter artifacts by scope before resolving/collecting it.

Why? The filter does it for us during the collection. For my test case, the provided dependency gets filtered out correctly.

When I was looking into this, I looked around the other sources. I saw org.apache.maven.project.DefaultProjectDependenciesResolver#resolve. It looks like the original code was trying to do what the DefaultProjectDependenciesResolver#resolve does, but the original code lacks few of the hacks that the DefaultProjectDependenciesResolver#resolve has. I was wondering, if that is why it was returning different results.

This looks correct in Maven3 universe. Due being in "maven3 universe" it suffers from MNG-8041, but is acceptable.

@cstamas we should be consequently - we did filtering before resolving in m-assembly-p
apache/maven-assembly-plugin#166

So how plugins should resolve dependencies tree with given scope ...?

another issue with the similar problem https://issues.apache.org/jira/browse/MINVOKER-368

Right. This all evolves around MNG-8041 where maven3 provides "wrong runtime" classpath/tree. Reason is that at the "start" in includes unwanted scopes like test scope, that "eclipses" possible runtime dependencies lower in tree, and finally dep filter removes "test" scope as well (and the losers are removed by conflict resolution before that) and classpath ends up being incomplete, as explained here: https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-11/common-misconceptions.html

So, I do agree with @slawekjaranowski we should align these plugin scattered "fixes", until Maven4 API generally provides fixed and one-shop solution for all.