Replace ResourceIterable with standard Java solutions

[mpkorstanje]

Cucumber-JVM has rather inconsistent support for uri's in the feature path.

For example: cucumber classpath:com/example/my/app.feature and cucumber src/main/java/com/example/my/app.feature work but cucumber file:src/test/resources/com/example/my/app.feature does not. Nor does cucumber hdfs:path/to/cloud/location/app.feature or any other protocol that could be supported by the jvm.

At the same time we do support custom ResourceIteratorFactory implementations but only for resources on the classpath So cucumber classpath:features.jar#!com/example/app.feature works but cucumber jar:src/test/resources/features.jar#!/com/example/app.feature does not.

In essence we are mimicking functionality provided by FileSystem and Path and are doing so poorly. Looking back in time this made sense as Cucumber was originally written for Java 6 when we didn't have nice things yet.

Never the less it makes it rather hard to explain what exactly the feature path is and what people can do with it. This can be resolved by:

• Ensuring that after parsing the feature path consists of proper URI's [Core] Formalize glue and feature paths #1544.
• Using Paths.get(URI uri), Files.walkFileTree and related utilities to scan and discover features. An example of this can be found in junit-jupiter/PathScanner. [Core] Replace ResourceIterable with standard Java solutions #1820

[mpkorstanje]

https://groups.google.com/forum/m/#!topic/cukes/MIJLvqapbK8

Tangentially related, the plugin system has the same issues now caused by the URLOutputStream

[34875634567]

Also I think current implementation is failing to load feature files from the classpath when embedded in a JAR on account of using the file: scheme.

[mpkorstanje]

That is correct.

[34875634567]

Related to this proposed fix:
https://stackoverflow.com/questions/44069165/cucumber-no-backend-found-when-running-from-spring-boot-jar

[mpkorstanje]

Nicely found.

[mpkorstanje]

#1117 (comment)

[It was not an option] to scan in the container (ie from the backend) since we can not have the right filesystem handling (jndi://, vfs://, ...)

Our home grown path scanning is also hindering the implementation of custom back ends.

[mlvandijk]

As #1544 was merged, does that mean first TODO is done?

[mpkorstanje]

Yes.

[mpkorstanje]

Another consideration. The resource loading should be provided as an interface that can be re implemented to facilitate various containers (e.g. a spring boot executable jar). In combination with a programmatic API this should make it possible to easily run cucumber tests from inside an application.

[mpkorstanje]

Reference to current problem/solutions with the spring jar:

• https://stackoverflow.com/a/46564059/3945473
• https://stackoverflow.com/questions/57995598