[Regression] Different requirement to get only the direct dependencies

[rfscholte]

Affected version

2.0.13

Bug description

Up until 2.0.11 when resolving only the direct dependencies you would use the following request:

new DependencyRequest(cr2, (_, b) -> b.size() <= 1)

As of 2.0.13 this has changed, because the path now has 2 elements: itself and null. To make it work, you need to use this:

new DependencyRequest(cr2, (_, b) -> b.size() <= 2)

I assume this is a regression.

[cstamas]

Well, this is not how one should resolve direct dependencies, as what happens in this case, is that you build the whole dirty tree (transitive and all) only to drop all of that in 2nd part (flattening with filter applied). I mean, it works obviously, but this approach is very wasteful.

The recommended way to resolve direct dependencies is basically just use org.eclipse.aether.RepositorySystem#resolveArtifacts method, with a list of direct dependencies, as this does only what it says, it does not collect and then drops all what it collected.

The change is most probably due this change:
80e0d60

Can you post some reproducer code snippet? As I still don't see how null comes into picture...

[cstamas]

And right, the difference before and after commit is obvious: the "old" FilteringDependencyVisitor calls filter with parents, while AbstractDependencyNodeConsumerVisitor with full path (self included). This obviously violates the contract of DependencyFilter:

    /**
     * Indicates whether the specified dependency node shall be included or excluded.
     *
     * @param node The dependency node to filter, must not be {@code null}.
     * @param parents The (read-only) chain of parent nodes that leads to the node to be filtered, must not be
     *            {@code null}. Iterating this (possibly empty) list walks up the dependency graph towards the root
     *            node, i.e. the immediate parent node (if any) is the first node in the list. The size of the list also
     *            denotes the zero-based depth of the filtered node.
     * @return {@code true} to include the dependency node, {@code false} to exclude it.
     */
    boolean accept(DependencyNode node, List<DependencyNode> parents);

[rfscholte]

Indeed, with a little bit of rewriting I was able to get the same result without this filter. IIRC I was inspired by some code in the maven-dependency-plugin, so maybe that should have a revisit too.

[cstamas]

@rfscholte pls create an issue in m-dep-p and pinpoint the place, as this is wasteful as I explained above... and yup, it should be fixed.