[MSHARED-998] NPE when resolving dependencies with PatternInclusionsFilter that holds a pattern with a classifier

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: maven-artifact-transfer-0.13.1
• Component/s: maven-artifact-transfer
• Assignee: Unassigned
• Reporter: Hans Aikema
• Created: 05/Oct/21 20:05
• Updated: 05/Oct/21 20:24

Description

After migrating from ArtifactResolver to DependencyResolver in OWASP DependencyCheck in order to properly take repositories into account that are expected to be added by the ancestry of a transitive dependency we received notifications of NullPointerExceptions during dependencyresolution in our plugin.

Analysis has led me to believe that its rootcause is a bug in Maven31DependencyResolver.

The issues in our project:

https://github.com/jeremylong/DependencyCheck/issues/3679

https://github.com/jeremylong/DependencyCheck/issues/3694

We call resolveDependencies(ProjectBuildingRequest , Collection<Dependency> , Collection<Dependency>, TransformableFilter) with an org.apache.maven.shared.artifact.filter.resolve.PatternInclusionsFilter.

This works fine for a pattern <group>:<artifact>:<extension>:<version>, but fails with an NPE for a pattern <group>:<artifact>:<extension>:<classifier>:<version>.

Maven31DependencyResolver implementation creates a root-less CollectRequest which is transformed into a DependencyRequest that is offered to the RepositorySystem.

The rootless (no root and no rootArtifact) CollectRequest results in a null-filled new DefaultDependencyNode(null) root to be received in the CollectResult in DefaultRepositorySystem.

This null-artifact root of the CollectResult then triggers the NPE (inside the filter constructed inside newAdvancedPatternInclusionFilter of org.apache.maven.shared.artifact.filter.resolve.transform.EclipseAetherFilterTransformer) when that filter tries to determine the classifier of the rootNode when the filtering visitor starts traversing the tree.