[
https://issues.apache.org/jira/browse/SUREFIRE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199426#comment-17199426
]
Michael Boyles edited comment on SUREFIRE-1842 at 9/21/20, 2:49 PM:
--------------------------------------------------------------------
The only thing which can throw NPE on that line is [this instance of
RunOrderCalculator|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java#L294]
This is the [only
implementation|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L113]
of the provider, and the return is indeed nullable.
This null check seems spurious. It checks directoryScannerParameters, but
doesn't use it for anything. Seems like it should be checking
runOrderParameters. When it was [originally
introduced,|https://github.com/apache/maven-surefire/blob/877873b08a8fb62c7d31a0019eb2a1b419a2876e/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L80]
this check made sense, but [a subsequent change to support parallelizing
tests|https://github.com/apache/maven-surefire/commit/13e6736b8cabc04be9b98c71a2a9695391d1f1a1#diff-868fd02a40a6474205d7b259d320b806L86]
seemed to break it.
As a workaround, the reason directoryScannerParameters is null stems from the
fact that [you are using
<suiteXmlFiles>|(https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1832],
so maybe you can find an alternative way to configure your tests, while
avoiding using that.
was (Author: michaelboyles):
The only thing which can throw is [this instance of
RunOrderCalculator|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreProvider.java#L294]
This is the [only
implementation|https://github.com/apache/maven-surefire/blob/b0325d4b7142832696d22fea1ea654348a69c675/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L113]
of the provider, and the return is indeed nullable.
This null check seems spurious. It checks directoryScannerParameters, but
doesn't use it for anything. Seems like it should be checking
runOrderParameters. When it was [originally
introduced,|https://github.com/apache/maven-surefire/blob/877873b08a8fb62c7d31a0019eb2a1b419a2876e/surefire-api/src/main/java/org/apache/maven/surefire/booter/BaseProviderFactory.java#L80]
this check made sense, but [a subsequent change to support parallelizing
tests|https://github.com/apache/maven-surefire/commit/13e6736b8cabc04be9b98c71a2a9695391d1f1a1#diff-868fd02a40a6474205d7b259d320b806L86]
seemed to break it.
As a workaround, the reason directoryScannerParameters is null stems from the
fact that [you are using
<suiteXmlFiles>|(https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1832],
so maybe you can find an alternative way to configure your tests, while
avoiding using that.
> Surefire - NPE at end of successful test run
> --------------------------------------------
>
> Key: SUREFIRE-1842
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1842
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.19.1, 2.21.0, 2.22.1, 3.0.0-M2, 3.0.0-M1, 3.0.0-M3,
> 3.0.0-M4
> Reporter: Jack Leech
> Priority: Major
> Attachments: stack_trace.txt, test_profile.xml
>
>
> While using surefire to run a mock test pack all tests are passed, followed
> by an exception in the surefire plugin (NPE) at the end which causes the run
> to be marked as a failure.
> I've tried various surefire versions of surefire and other testing libraries
> involved.
> I have attached a stack trace of the exception in question and a copy of the
> test profile xml.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
