What steps will reproduce the problem?

My project layout (simplified): /lib.js /js/jsTestDriver.conf /js/test/libTest.js

The jsTestDriverConf: server: http://localhost:9876 load: - ../lib.js test: - test/*.js

What is the expected output? What do you see instead?

When I execute (with /js being the current folder), the compiler says: error loading file: /test/../lib.js: [object Event] error loading file: /test/test/libTest.js: [object Event]

Even though it finds the file, because when I give a wrong path to lib.js, it says the usual: java.lang.IllegalArgumentException: The patterns/paths used in the configuration file didn't match any file, the files patterns/paths need to be relative

What version of the product are you using? On what operating system? JsTestDriver-1.3.2.jar Mac OS X 10.6.7

Please provide any additional information below. I've attached a sample of my setup that will produce the error (execute with /js as the current folder)

I'm seeing the same thing. It doesn't seem to be calculating relative paths correctly.

I've the same problem. And it's not a problem with the relative paths itself. It seems to be a problem with the TestRunner that doesn't work properly when the relative path must to go up some levels in the hierarchy folders.

Same shit on Ubuntu 10.10. I'm using JsTestDriver-1.3.2.jar.

Same issue here (using IntelliJ-Plugin). Seems the PathResolver has issues when using relative paths.

My project layout: /src/test/resources/jsTestDriver.conf /src/main/webapp/js/dummy.js /src/test/webapp/js/dummy.js

Config: load: - ../../main/webapp/js/dummy.js - ../../test/webapp/js/dummy.js

1.2.2b version created the following path: /test/C:/Users/username/workspace/project/src/main/webapp/js/dummy.js 1.3.2 creates: /test/../../main/webapp/js/dummy.js

In PathResolver.java, is it intentional that File.separator is used when parsing these files? That would seem to mean that we need to make up different configuration files based on the Operating system we are running on?

My Config file looks like: load: - ../src/main/webapp/scripts/.js - ../src/main/webapp/scripts/external/.js

test: - ../src/test/javascript/*.js

The actual file structure I am using is:

conf/jsTestDriver.conf src/test/javascript/test.js src/main/webapp/scripts/test.js src/main/webapp/scripts/external/jquery-1.6.2.js

The error I am getting when I run this (using the trunk version at r985, and the last relevant changes seem to be at r922) on Windows (as I didn't expect the file to be platform dependent) is:

java.util.regex.PatternSyntaxException: Unexpected internal error near index 1 \ ^ at java.util.regex.Pattern.error(Pattern.java:1713) at java.util.regex.Pattern.compile(Pattern.java:1466) at java.util.regex.Pattern.(Pattern.java:1133) at java.util.regex.Pattern.compile(Pattern.java:823) at java.lang.String.split(String.java:2292) at java.lang.String.split(String.java:2334) at com.google.jstestdriver.PathResolver.resolveRelativePathReferences(PathResolver.java:142) at com.google.jstestdriver.PathResolver.resolvePath(PathResolver.java:60) at com.google.jstestdriver.PathResolver.resolve(PathResolver.java:99) at com.google.jstestdriver.config.ParsedConfiguration.resolvePaths(ParsedConfiguration.java:89) at com.google.jstestdriver.config.Initializer.initialize(Initializer.java:91) at com.google.jstestdriver.JsTestDriver.runConfigurationWithFlags(JsTestDriver.java:257) at com.google.jstestdriver.JsTestDriver.runConfiguration(JsTestDriver.java:209) at com.google.jstestdriver.JsTestDriver.main(JsTestDriver.java:142) Unexpected Runner Condition: Unexpected internal error near index 1 \

I only ran "ant jar" before, so I thought I should also run "ant test"

It looks like the ConfigurationParseTest is currently broken in the trunk svn due to errors:

[junit] Running com.google.jstestdriver.ConfigurationParserTest
[junit] Tests run: 9, Failures: 0, Errors: 5, Time elapsed: 0.391 sec

Attaching the junit xml file to this comment

Why is jsTestDriver in version 1.3.2? For me looks very unstable with a lot of unresolved problems. 0.3.2 would fit better...

Judging the maturity of software by its version number is a relic of decades past and almost always a mistake. There is no standard when choosing version numbers so what does it matter if it's 1.3.2, 0.3.2 or 13.2 it is an arbitrary number that gives you no idea where it stands without a point of reference.

You should have tried it in 0.xxx stages.

It's actually remarkably stable for a very distinct set of cases. It's just that there are some use cases that were outside of the initial design, and therefore poorly supported.

I partly agree, but only if you - apart from version number - provide the users with some information about the stability of the product. Unless you do so, I will assume (based on the version number, if there's nothing else) that I can use your product in a production environment and I can build my infrastructure on it.

It it's not the version number, there must be big red letters on the homepage saying UNSTABLE, ALPHA, BUGGY whatever...

I don't want to be mean, but it's interesting, that for this comment I got answer within minutes, though my open issues are uncommented for long long time.

However, I think it is a great project, a nice idea, and you guys did a great job so far. I'm just a little but disappointed for all the struggles I need to go thru with js-test-driver, and at the end, it might not even work at all.

Only because I'm starting to go through the backlog. I haven't had much time as of late.

OK, thank you very much! :)

Fixed on head. Next release should resolve this.

When can we expect this to be released? We are trying decide on a javascript framework and this is a blocker.

So I tried checking out the source and building, but I'm getting the following error (it's probably relevant to note that I'm running on Windows:

java.util.regex.PatternSyntaxException: Unexpected internal error near index 1 \ ^ at java.util.regex.Pattern.error(Pattern.java:1713) at java.util.regex.Pattern.compile(Pattern.java:1466) at java.util.regex.Pattern.(Pattern.java:1133) at java.util.regex.Pattern.compile(Pattern.java:823) at java.lang.String.split(String.java:2292) at java.lang.String.split(String.java:2334) at com.google.jstestdriver.PathResolver.resolveRelativePathReferences(PathResolver.java:142) at com.google.jstestdriver.PathResolver.resolvePath(PathResolver.java:60) at com.google.jstestdriver.PathResolver.resolve(PathResolver.java:99) at com.google.jstestdriver.config.ParsedConfiguration.resolvePaths(ParsedConfiguration.java:88) at com.google.jstestdriver.config.Initializer.initialize(Initializer.java:91) at com.google.jstestdriver.JsTestDriver.runConfigurationWithFlags(JsTestDriver.java:257) at com.google.jstestdriver.JsTestDriver.runConfiguration(JsTestDriver.java:209) at com.google.jstestdriver.JsTestDriver.main(JsTestDriver.java:142)

I tried checking out the source code for building the IntelliJ-Plugin, no luck :-(

Building jstestdriver on WindowsXP was no problem. @dgalla: do you see this error on building or during testing?

I'm having the same issue, so I tried to use the head of the trunk to fix it : - the build was successful, but when ran, same error as @dgallardo ( java.util.regex.PatternSyntaxException: Unexpected internal error near index 1 \ in PathResolver.resolveRelativePathReferences)

The problem is (apparently) easy to fix, in PathResolver, line 143, quote the File.separator before using it with the split method :

String[] elements = path.split(Pattern.quote(File.separator));

And for the explanation, the File.separator in Windows is "\", which is the escape character character in regular expressions. And String#split(...) parameter is applied as a regex, thus the pattern compilation error.

I can confirm that the fix I have suggested just above will fix the PatternSyntaxException problem and relative path are now working as expected.

Could you apply this patch to the trunk ? When do you plan the next release of jstd ?

Soon, soon. Probably next week if I can get the last bugs ironed out. I'm trying release with fewer bugs, not more.

The sad part is I distinctly remember making a change to fix this and checking it in. I'm now presented with the choice of either finding the mess up, or just fixing it. :p Both are going to be unfulfilling.

Maybe you checked it in your local GIT repository, and forget to push it to the SVN ;) I can understand your frustration, fixing a bug twice is never a good sign ... ! Anyway, thank you for your answer. I'll be waiting for the next release.

Yeah, too bad that this project has Google relations so you guys have to stick to Google Code... maybe it would be easier to contribute on github, for example. ;)

Actually, as soon as I verify the transition, it will change to git on Google Code.

Just want to make sure I don't accidentally delete the repository.

Still no forking and pull requests or any easy way to contribute in Google Code afaik :(

I tried fixing the PatternSyntaxException too, by changing the split parameter to Pattern.quote(File.separator), but then I got the original IllegalArgumentException.

@dgalla : Are you using the HEAD of the trunk ? or did you just patched an existing source checkout ? I have exactly the same configuration as you regarding the use of relative path, and using HEAD+quotepatch made it work as expected.

Here's a link to what appears to be the fix for this issue:

http://code.google.com/p/js-test-driver/source/detail?r=919

The problem keeps appearing in a JAR compiled from HEAD :(

Try it after r1027, and let me know.

Patch attached with the fix (also removing some extra whitespaces :)) Tested and worked for me.

Release 1.3.3a

Both 1.3.3a and HEAD appear to still have this problem. The patch in comment 30 fixed this for me though.

Finally got around to trying 1.3.3c and it's working.. brilliant, thanks!

Comment deleted

Configuration file, please?

Comment deleted

Comment deleted

Since the pattern says *.js it seems a reasonable assumption.

This bug comes back in 1.3.4-a and it works fine in 1.3.3-d.

Please provide a configuration file.

It actually comes back with the test case originally attached to this issue. I tried 1.3.4.b and already when starting the server it fails with:

java.lang.RuntimeException: Impossible to read file: /sample/js/lib.js at com.google.jstestdriver.SimpleFileReader.readFile(SimpleFileReader.java:50) at com.google.jstestdriver.FileInfo.loadFile(FileInfo.java:203) at com.google.jstestdriver.ProcessingFileLoader.loadFiles(ProcessingFileLoader.java:61) at com.google.jstestdriver.model.JstdTestCaseDelta.loadFiles(JstdTestCaseDelta.java:59) at com.google.jstestdriver.FileUploader.uploadToServer(FileUploader.java:218) at com.google.jstestdriver.action.UploadAction.run(UploadAction.java:39) at com.google.jstestdriver.ActionRunner.runActions(ActionRunner.java:81) at com.google.jstestdriver.embedded.JsTestDriverImpl.runConfigurationWithFlags(JsTestDriverImpl.java:342) at com.google.jstestdriver.embedded.JsTestDriverImpl.runConfiguration(JsTestDriverImpl.java:233) at com.google.jstestdriver.Main.main(Main.java:70) Caused by: java.io.FileNotFoundException: /sample/js/lib.js (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:120) at java.io.FileInputStream.(FileInputStream.java:79) at com.google.jstestdriver.SimpleFileReader.readFile(SimpleFileReader.java:34) ... 9 more

Although it finds the file, because if it simply doesn't exist it fails with:

Configuration Error: Cannot read [ /sample/js/./../xlib.js /sample/js/./xlib.js ] derived from xlib.js

Maybe it would work with the multiple basePath attribute, but I couldn't figure out how to use that in the config file...

I see the same in 1.3.4b, config:

server: http://localhost:42442

load: - ../3party/jquery/jquery-1.7.1/jquery.min.js - js/.js - testing/.js

stacktrace: java.lang.RuntimeException: Impossible to read file: D:\jvr\Workspace\bw\wfs_feature_finder.\3party\jquery\jquery-1.7.1\jquery.min.j s at com.google.jstestdriver.SimpleFileReader.readFile(SimpleFileReader.ja va:50) at com.google.jstestdriver.FileInfo.loadFile(FileInfo.java:203) at com.google.jstestdriver.ProcessingFileLoader.loadFiles(ProcessingFile Loader.java:61) at com.google.jstestdriver.model.JstdTestCaseDelta.loadFiles(JstdTestCas eDelta.java:59) at com.google.jstestdriver.FileUploader.uploadToServer(FileUploader.java :218) at com.google.jstestdriver.action.UploadAction.run(UploadAction.java:39)

    at com.google.jstestdriver.ActionRunner.runActions(ActionRunner.java:81)

    at com.google.jstestdriver.embedded.JsTestDriverImpl.runConfigurationWit

hFlags(JsTestDriverImpl.java:342) at com.google.jstestdriver.embedded.JsTestDriverImpl.runConfiguration(Js TestDriverImpl.java:233) at com.google.jstestdriver.Main.main(Main.java:70)

I also see the same issue, relative paths are broken in 1.3.4.b and working in 1.3.3c for me in WinXP with either a basepath set in the jsTestDriver.conf like so: basepath: ../../../..

or with that relative path set on every entry in the config file.

The first stage looks in the correct place, and the second stage where it tries to actually load the file appears to strip one of the ../ path sections off, so the correct path will fail with "Impossible to open file" and if you add an extra .. to your path it will fail earlier with "path does not match any file"

This fairly trivial bit of path parsing seems to have been a major issue for js-test-driver for the past 6 months or more. I'd recommend integrating the wildcard library - http://code.google.com/p/wildcard/ and then you can also use it's full path globbing capability, so use users can write config like ../..//modules//src//.js.

Are there any news on this bug? I can see it's still marked as "Fixed", but it's definitely back in 1.3.4.b.

I see this issue in 1.3.4.b.

Can still reproduce on 1.3.5 on OS X

Also cannot use absolute paths - the current path is prepended to anything passed in.

Gosh this has been going on for ages

Didn't notice that 1.3.5 was released! The example I attached to this issue originally works for me with 1.3.5 on OS X. It also works on my real project.. seems fixed to me.

I'm still able to reproduce this issue with 1.3.5, but not with 1.3.3d (I'm using the same jsTestDriver.conf file) - comment #43 accurately describes the same situation and symptoms I'm getting.

Is there any workaround for this besides sticking with the older version?

still an issue for 1.3.5. Tested on Windows 7

Should we re-open this? Start a new one? I've tested this on Windows 7 too, still a problem. I need to pass parameters in the browser element, so I need 1.3.4 or later. I'm working around it by running jstd through vanilla exec plugin. It feels like such a hack..

The world has moved on. Nowadays the cool people are using Karma test runner instead of jstd. Way faster and more stable.