Allow third parties to provide a custom ClasspathScanner implementation

[yuuki3655]

The Jupiter and Vintage engines use org.junit.platform.commons.util.ClasspathScanner to discover test classes in the classpath. The ClasspathScanner scans directories and looks for class files. It works fine for a standard JVM process; however, it needs to be customized for a specific environment such as Android.

A possible solution for this is to make the ClasspathScanner an interface and load the implementation via the ServiceLoader mechanism.

public interface ClasspathScanner {
	static ClasspathScanner getInstance() {
		ServiceLoader<ClasspathScanner> serviceLoader = ServiceLoader.load(ClasspathScanner.class);
		for (ClasspathScanner scanner : serviceLoader) {
			return scanner;
		}
		return new DefaultClasspathScanner(ClassLoaderUtils::getDefaultClassLoader, ReflectionUtils::tryToLoadClass);
	}

	List<Class<?>> scanForClassesInPackage(String basePackageName, ClassFilter classFilter);

	List<Class<?>> scanForClassesInClasspathRoot(URI root, ClassFilter classFilter);
}

Then, we could provide the Android-specific implementation with androidx.test.internal.runner.ClassPathScanner, for example.

This change would make the Jupiter and Vintage engines work in Android.

[marcphilipp]

Thanks for the proposal! It'd be awesome to get Jupiter and Vintage working out-of-the-box on Android. I'll discuss it with the team and will get back to you.

[sbrannen]

SGTM.

Let's put that interface in the org.junit.platform.commons.support.scanning package.

[marcphilipp]

Team decision: Let's follow the proposal but wait for #3630 to be done first.