Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/150
The fast way would be to give it a try in a copy of your project apart and
run the local build
"mvn install -P run-its -Dcheckstyle.skip=true".
Even if you copied FilterFactory into JUnit47 provider and used this loop
as you have mentioned above and build it, it would be safer for you. If the
build will be finally successful, we will just move the class FilterFactory
to the module common-junit4, refactor usages and then patch the JUnit4
provider in this PR.
On Sat, Dec 23, 2017 at 9:25 PM, M.P. Korstanje <[email protected]>
wrote:
> @Tibor17 <https://github.com/tibor17> that should be doable. Replacing
> the inner most loop in the JUnit4Provider.executeWithRerun with the code
> below should do it. This would require the FilterFactory to be moved to
> another common module. I can't quite tell what the the nock-on effects of
> that would be.
>
> for ( int i = 0; i < rerunFailingTestsCount &&
!failureListener.getAllFailures().isEmpty(); i++ )
> {
> Set<Description> failures = generateFailingTestDescriptions(
failureListener.getAllFailures() );
> failureListener.reset();
> FilterFactory filterFactory = new FilterFactory( testClassLoader );
> Filter failingMethodsFilter =
filterFactory.createMatchMethodDescriptionsFilter( failures );
> Request.aClass( clazz ).filterWith( failingMethodsFilter
).getRunner().run( rerunNotifier );
> }
>
> â
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
>
<https://github.com/apache/maven-surefire/pull/150#issuecomment-353746273>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AA_yR-4dWYNw6T5vwzi-xzC6CWnSZL9yks5tDWG4gaJpZM4NoCQj>
> .
>
--
Cheers
Tibor
---
