Ranie Jade Ramiso

@arturbosch Thanks for the report! I suspect this line https://github.com/spekframework/spek/blob/60c14fedfb85bfad2e2405406309385cc912f1b8/spek-runtime/src/jvmMain/kotlin/org/spekframework/spek2/runtime/JvmDiscoveryContextFactory.kt#L48 is causing the whole classpath to be scanned. I'll try making the scan asynchronous https://github.com/spekframework/spek/blob/60c14fedfb85bfad2e2405406309385cc912f1b8/spek-runtime/src/jvmMain/kotlin/org/spekframework/spek2/runtime/JvmDiscoveryContextFactory.kt#L52 - hopefully it will help....

> Would it be possible to restrict the scanning to some user defined packages? I can look at that, but I don't think Gradle's implementation of JUnit 5 support is...

Thanks for the report @edwinRNDR! This looks like related to #805. With #835 (coroutine support), I think you can create your own dispatcher (from a single thread) and use `launch`...

The current implementation of #835 runs on the main thread actually but that will change (will probably use `Dispatchers.Default`). Bootstrapping of spek happens on the main thread (gradle and IJ),...

Haven't thought about it that much, but in the case for `kotlin-test` support is built-in into the kotlin compiler itself.

Not sure on how to fix this, the classpath the plugin uses is provided by AS itself. Do you have the same problem if you run a JUnit 4 test...

Actually, `android.jar` should not be in the classpath - the plugin has some special logic to remove android jars and replace them with mockable versions.

@orospakr is this still an issue with AS 3.4? Tested it on a project and it puts `android.jar` at the end of the classpath.

`2.0.17` is out which contain the fix, @DebashisPorter can you verify that it is working for you?

Thanks for the report @Misoder, have you tried invalidating the cache? Also can you provide a sample project that can replicate the issue?