Replace ResourceIterable with standard Java solutions #1526
Milestone
Comments
mpkorstanje
changed the title
|
https://groups.google.com/forum/m/#!topic/cukes/MIJLvqapbK8 Tangentially related, the plugin system has the same issues now caused by the URLOutputStream |
|
Also I think current implementation is failing to load feature files from the classpath when embedded in a JAR on account of using the |
|
That is correct. |
|
Related to this proposed fix: |
|
Nicely found. |
Our home grown path scanning is also hindering the implementation of custom back ends. |
Closed
|
As #1544 was merged, does that mean first TODO is done? |
|
Yes. |
|
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. |
|
Reference to current problem/solutions with the spring jar: |
mpkorstanje
added a commit
that referenced
this issue
Sep 22, 2019
Introduces the backend module. With this module backend implementations only need to use dependencies from `io.cucumber.core.backend`. This will allow us to introduce the module system later on The implementation is not yet perfect. Classpath scanning and resource loading is located in other modules. Removing this depends on #1526 and removal of type registry configurer which depends on #1768 . Fixes #1386 because steps can now see if an exception came from user code or actual backend. Removes timeout which would close #1695 earlier then expected.
mpkorstanje
added a commit
that referenced
this issue
Nov 15, 2019
`ResourceIterable` provides inconsistent support for URI's. Supported: * file:path/to.feature * classpath:com/example.feature * classpath:features.jar#!com/example.feature Unsupported: * jar:path/to.jar#!/com/example.feature * any-jvm-supported-file-system:path/to.feature Replacing `ResourceIterable` with `FileSystem` and `Path` adds consistent support for URI's and reduces the complexity of scanning for classes and resources significantly. Both `ClasspathScanner` and `ResourceScanner` are instantiated with a ClassLoader for all class path operations. This should allow Cucumber access to platforms use fat jars and other packaging methods. Fixes: #1526
6 tasks
mpkorstanje
added a commit
that referenced
this issue
Nov 16, 2019
`ResourceIterable` provides inconsistent support for URI's. Supported: * file:path/to.feature * classpath:com/example.feature * classpath:features.jar#!com/example.feature Unsupported: * jar:path/to.jar#!/com/example.feature * any-jvm-supported-file-system:path/to.feature Replacing `ResourceIterable` with `FileSystem` and `Path` adds consistent support for URI's and reduces the complexity of scanning for classes and resources significantly. Both `ClasspathScanner` and `ResourceScanner` are instantiated with a ClassLoader for all class path operations. This should allow Cucumber access to platforms use fat jars and other packaging methods. Fixes: #1526
mpkorstanje
added a commit
that referenced
this issue
Nov 17, 2019
`ResourceIterable` provides inconsistent support for URI's. Supported: * file:path/to.feature * classpath:com/example.feature * classpath:features.jar#!com/example.feature Unsupported: * jar:path/to.jar#!/com/example.feature * any-jvm-supported-file-system:path/to.feature Replacing `ResourceIterable` with `FileSystem` and `Path` adds consistent support for URI's and reduces the complexity of scanning for classes and resources significantly. Both `ClasspathScanner` and `ResourceScanner` are instantiated with a ClassLoader for all class path operations. This should allow Cucumber access to platforms use fat jars and other packaging methods. Fixes: #1526
mpkorstanje
added a commit
that referenced
this issue
Nov 21, 2019
* Implement proof of concept of JUnit Test Engine for cucumber * Run all tests in a package * Clean up tests * Add logging * Add test for FeatureResolver * Clean up * Clean up * Map test case results to junit results * Minor clean up * Rename to JUnit Platform Engine * Add class path resolver * Assert against optional * Add uri resolver * Add JUnit 5 example * Add parallel support * Add support for selected options * Add support for TestTags * Add support for package filtering * Refactor things * [Core] Normalize input when parsing To avoid having to deal with path separators everywhere all paths have their separators replaced with a forward slash while parsing runtime options. To make this easier all rerun files are also read while parsing runtime options. As a result we can now also emit an error when a feature file that explicitly included (e.g. /path/to.feature) does not exist. * Add resolve by UniqueId * Polish * [Core] Implement equals and hashcode on CucumberFeature * [Core] Re-encode string without re-reading resource * [Jupiter] Use uri in feature segment of UniqueId * [Jupiter] Reduce class visibility * [Jupiter] Extract resource package * [Core] Revert encoding fix * [Jupiter] Polish * [Jupiter] Polish * WIP * Add notes and stuff * More notes * Fix stuff * Fix stuff * Fix more * Fix more * Clean up constants * Fix more classpath * Notes * Fix moved packages * Bump version * Fix stuff * Map to test description usint recursive descent on ast * Clean up * Clean up * Clean up resource scanner * Clean up resource scanner * Use lambda logging * WIP * WIP: * WIP * WIP * WIP * WIP * WIP * [Core] Replace ResourceIterable with standard Java solutions `ResourceIterable` provides inconsistent support for URI's. Supported: * file:path/to.feature * classpath:com/example.feature * classpath:features.jar#!com/example.feature Unsupported: * jar:path/to.jar#!/com/example.feature * any-jvm-supported-file-system:path/to.feature Replacing `ResourceIterable` with `FileSystem` and `Path` adds consistent support for URI's and reduces the complexity of scanning for classes and resources significantly. Both `ClasspathScanner` and `ResourceScanner` are instantiated with a ClassLoader for all class path operations. This should allow Cucumber access to platforms use fat jars and other packaging methods. Fixes: #1526 * [Core] Classpath scanning inside nested Jars is not supported. Spring Boot provides an executable jar format that packages the application and all dependencies into a self contained jar[1]. This format doesn't follow regular jar layouts making it harder to scan. Cucumber currently doesn't support this use case and will throw an error if nested jars are detected. As a work around users can unpack their application before executing. - [1] https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-executable-jar-format.html * Fix typos * GroupId and artifactId are provided by default implemenation * Print snippets after test * Use ant to run Junit platform * Update readme * Update readme * Update readme * Add report output * Make scenario and outline synonims * Update readme * Clean up * Use Gherkin compatibility objects to build feature descriptor * Update readme * Better example names * Better example names * Better module name * Better module name * Fix concurrent reading of features * Read jar files concurrently * Use default class loaders util
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Cucumber-JVM has rather inconsistent support for uri's in the feature path.
For example:
cucumber classpath:com/example/my/app.featureandcucumber src/main/java/com/example/my/app.featurework butcucumber file:src/test/resources/com/example/my/app.featuredoes not. Nor doescucumber hdfs:path/to/cloud/location/app.featureor any other protocol that could be supported by the jvm.At the same time we do support custom
ResourceIteratorFactoryimplementations but only for resources on the classpath Socucumber classpath:features.jar#!com/example/app.featureworks butcucumber jar:src/test/resources/features.jar#!/com/example/app.featuredoes not.In essence we are mimicking functionality provided by
FileSystemandPathand 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:
Paths.get(URI uri),Files.walkFileTreeand 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 #1820The text was updated successfully, but these errors were encountered: