[
https://issues.apache.org/jira/browse/MSHARED-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hans Aikema updated MSHARED-998:
--------------------------------
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)|https://github.com/apache/maven-artifact-transfer/blob/ea7e7af3a97dda668166c481c3eb075bca5b51d6/maven-artifact-transfer-api/src/main/java/org/apache/maven/shared/transfer/dependencies/resolve/DependencyResolver.java#L76]
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.
was:
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)|https://github.com/apache/maven-artifact-transfer/blob/ea7e7af3a97dda668166c481c3eb075bca5b51d6/maven-artifact-transfer-api/src/main/java/org/apache/maven/shared/transfer/dependencies/resolve/DependencyResolver.java#L76]
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 than 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.
> NPE when resolving dependencies with PatternInclusionsFilter that holds a
> pattern with a classifier
> ---------------------------------------------------------------------------------------------------
>
> Key: MSHARED-998
> URL: https://issues.apache.org/jira/browse/MSHARED-998
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-artifact-transfer
> Affects Versions: maven-artifact-transfer-0.13.1
> Reporter: Hans Aikema
> Priority: Major
>
> 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)|https://github.com/apache/maven-artifact-transfer/blob/ea7e7af3a97dda668166c481c3eb075bca5b51d6/maven-artifact-transfer-api/src/main/java/org/apache/maven/shared/transfer/dependencies/resolve/DependencyResolver.java#L76]
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
