ResourceLoader strategy should be decided by Backend

[aslakhellesoy]

Currently the ResourceLoader strategy is made by the runner (JUnit runner or CLI runner). JUnit uses ClasspathResourceLoader and CLI uses FileSystemResourceLoader. This is no good - it has to be done by the Backend.

For initial discussion see https://groups.google.com/d/msg/cukes/esUoT68FX5s/zCkUa6FzkYAJ

[dkowis]

Hmm, I never encountered this, perhaps because we put our ruby step def files in the class path, and reference them by the full path from the CLI, interesting... So certain backends would use certain loaders? Or the loader would somehow be specified by the Glue Path? Maybe I don't completely understand what you mean about having the backend do it.

[aslakhellesoy]

The problem is that currently, the JUnit runner will only load resources (.feature files and glue code) from the classpath. Absolute paths or even relative paths from the current directory will not be loaded (unless your current directory happens to be on the classpath).

Likewise, the CLI runner will only load resources from the file system. It won't look at the classpath at all.

This is a problem if you want to package features and glue inside a jar and use the java backend with the CLI runner. There is no way the resources will be loaded.

[dkowis]

Ah, I see now. That sounds like an excellent idea.

[aslakhellesoy]

The backends should know resource loader to use:

• Java -> Classpath
• JRuby -> FileSystem
• Groovy -> Classpath + FileSystem

etc.

[dkowis]

Jruby could use the classpath loader as well. Finding ruby files in a package isn't a wrong way to do things. I'd assume it'd differentiate depending on the type of glue path passed in?

But I see your point, it makes sense to put the stuff in the backend.

[devshido]

I like what has been proposed so far, I also think it makes sense that the backend should decide how to load the resources.

[aslakhellesoy]

Turns out this is a little tricky. Some people use multiple backends in one run (for example java and jruby).

This means there isn't a single backend that can decide how to load features.

I'm tempted to introduce special notation to separate file system resources from classpath resources.

For example foo/bar would mean a resource on the file system and :foo/bar would mean a resource on the classpath.

An alternative solution would be to make no such distinction (like now), but instead always load resources from both the filesystem and the classpath. The drawback of this approach is that there might be dupes or even unwanted resources.

What do you think?

[devshido]

Some people use multiple backends in one run (for example java and jruby).

Ahh, so you mean for instance, Step Definitions could be written in Groovy and the Features run through JUnit so both the JavaBackend and the GroovyBackend would be on the classpath? If that's what you mean then yes, I see the problem.

I don't think that the alternative solution is a good one really, it may cause unexpected issues and you'll probably have people asking for a way to include/exclude particular paths. So, the special notation would be better, but I don't think you can implement that without breaking code people have already written.

[dkowis]

I don't like the special notation... Is there a way for the file based resources to (like not an actual class) to be hashed and stored? so if it's duped, we don't load it again? Or would that be too much work?

[devshido]

Hi, props for the speed of getting something together on this!

I've not tried to use this yet but looking at the commit log on Github I don't think the change is a transparent one for JUnit runners, after looking at the change in junit/src/test/java/cucumber/junit/CucumberTest.java

Won't they have to add classpath:// to each Runner class?

[aslakhellesoy]

@C0deAttack If you explicitly want to specify the feature path in JUnit you now have to do @Cucumber.Options(features = "classpath:my/features"). However, if you don't, it will default to classpath:path/of/the/junit/class/package.

I think most people rely on the default so I don't think this will affect many people.

Does that answer your question?

[devshido]

Yep - I see, I just wanted to raise it just in case since you said it'd be a transparent change.

I've tested this change from the resource_loading branch and everything works fine. I tested:

• JUnit Runner with Feature on Classpath
• JUnit Runner with Feature on Filesystem
• CLI with Feature on Classpath
• CLI with Feature on Filesystem
• CLI (through executable Jar) with Feature on Jar's Classpath

My build guy is going to be happy!

[aslakhellesoy]

Thanks a lot for testing it out! I'll try to release this as soon as I can.

[aslakhellesoy]

Fixed in 1.0.6!

[devshido]

Nice, thanks for the effort and the quick turnaround :-)

[ayoseg]

Please tell me how you are running the executable jar from the command line (CLI (through executable Jar) with Feature on Jar's Classpath). I am executing java -jar Project.jar but I am getting

Exception in thread "main" cucumber.runtime.CucumberException: No features found
at
at cucumber.runtime.model.CucumberFeature.load(CucumberFeature.java:47)
at cucumber.runtime.RuntimeOptions.cucumberFeatures(RuntimeOptions.java:
93)
at cucumber.runtime.Runtime.run(Runtime.java:81)
at cucumber.cli.Main.run(Main.java:20)
at cucumber.cli.Main.main(Main.java:12)

I added the following to my Junit class, do I need to also specify it on the command line?

@Cucumber.Options(features = "classpath:uk/co/mycomany", glue = "uk.co.mycompany.provisionStepsDef", format= {"pretty", "html:target/cucumber", "json:target/cucumber.json"})

[aslakhellesoy]

@ayoseg this is a (fixed) bug in a bug tracker, not a discussion forum. Please use the mailing list if you have questions.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.