search

LiTiang / js-test-driver

Automatically exported from code.google.com/p/js-test-driver
0 stars 0 forks source link

Problem with relative paths in config since version 1.3.2 #223

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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)

Original issue reported on code.google.com by meyer...@gmail.com on 4 Apr 2011 at 4:49

Attachments:

GoogleCodeExporter commented 9 years ago 
I'm seeing the same thing.  It doesn't seem to be calculating relative paths 
correctly.

Original comment by burke.we...@gmail.com on 4 Apr 2011 at 9:27

GoogleCodeExporter commented 9 years ago 
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.

Original comment by amisc...@gmail.com on 6 Apr 2011 at 7:37

GoogleCodeExporter commented 9 years ago 
Same shit on Ubuntu 10.10.
I'm using JsTestDriver-1.3.2.jar.

Original comment by lukasz.p...@gmail.com on 7 Apr 2011 at 12:35

GoogleCodeExporter commented 9 years ago 
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

Original comment by plante...@gmail.com on 10 May 2011 at 1:52

GoogleCodeExporter commented 9 years ago 
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.<init>(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
\

Original comment by ansell.p...@gmail.com on 19 Jul 2011 at 2:13

GoogleCodeExporter commented 9 years ago 
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

Original comment by ansell.p...@gmail.com on 19 Jul 2011 at 2:29

Attachments:

GoogleCodeExporter commented 9 years ago 
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...

Original comment by tczol...@gmail.com on 28 Jul 2011 at 2:18

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jared.mc...@gmail.com on 28 Jul 2011 at 2:26

GoogleCodeExporter commented 9 years ago 
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.

Original comment by corbinrs...@gmail.com on 28 Jul 2011 at 2:30

GoogleCodeExporter commented 9 years ago 
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.

Original comment by tczol...@gmail.com on 28 Jul 2011 at 2:33

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

Original comment by corbinrs...@gmail.com on 28 Jul 2011 at 2:48

GoogleCodeExporter commented 9 years ago 
OK, thank you very much! :)

Original comment by tczol...@gmail.com on 28 Jul 2011 at 2:50

GoogleCodeExporter commented 9 years ago 
Fixed on head. Next release should resolve this.

Original comment by corbinrs...@gmail.com on 28 Jul 2011 at 2:51

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

Original comment by dgalla...@gmail.com on 3 Aug 2011 at 2:22

GoogleCodeExporter commented 9 years ago 
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.<init>(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)

Original comment by dgalla...@gmail.com on 3 Aug 2011 at 2:48

GoogleCodeExporter commented 9 years ago 
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?

Original comment by plante...@gmail.com on 3 Aug 2011 at 7:32

GoogleCodeExporter commented 9 years ago 
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));

Original comment by olivier....@gmail.com on 3 Aug 2011 at 2:14

GoogleCodeExporter commented 9 years ago 
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.

Original comment by olivier....@gmail.com on 3 Aug 2011 at 2:18

GoogleCodeExporter commented 9 years ago 
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 ?

Original comment by olivier....@gmail.com on 3 Aug 2011 at 2:52

GoogleCodeExporter commented 9 years ago 
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.

Original comment by corbinrs...@gmail.com on 3 Aug 2011 at 2:57

GoogleCodeExporter commented 9 years ago 
<troll>Maybe you checked it in your local GIT repository, and forget to push it 
to the SVN ;)</troll>
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.

Original comment by olivier....@gmail.com on 3 Aug 2011 at 3:06

GoogleCodeExporter commented 9 years ago 
<troll>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. ;) </troll>

Original comment by tczol...@gmail.com on 3 Aug 2011 at 3:15

GoogleCodeExporter commented 9 years ago 
<feeding the trolls>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.</feeding the 
trolls>

Original comment by corbinrs...@gmail.com on 3 Aug 2011 at 3:30

GoogleCodeExporter commented 9 years ago 
<bellyful_troll>Still no forking and pull requests or any easy way to 
contribute in Google Code afaik :( </bellyful_troll>

Original comment by tczol...@gmail.com on 3 Aug 2011 at 3:34

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

Original comment by dgalla...@gmail.com on 3 Aug 2011 at 5:34

GoogleCodeExporter commented 9 years ago 
@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.

Original comment by olivier....@gmail.com on 4 Aug 2011 at 8:17

GoogleCodeExporter commented 9 years ago 
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

Original comment by dominic....@gmail.com on 6 Sep 2011 at 2:14

GoogleCodeExporter commented 9 years ago 
The problem keeps appearing in a JAR compiled from HEAD :(

Original comment by tczol...@gmail.com on 6 Sep 2011 at 2:16

GoogleCodeExporter commented 9 years ago 
Try it after r1027, and let me know.

Original comment by corbinrs...@gmail.com on 6 Sep 2011 at 9:59

GoogleCodeExporter commented 9 years ago 
Patch attached with the fix (also removing some extra whitespaces :))
Tested and worked for me.

Original comment by tczol...@gmail.com on 14 Sep 2011 at 5:43

Attachments:

GoogleCodeExporter commented 9 years ago 
Release 1.3.3a

Original comment by corbinrs...@gmail.com on 29 Sep 2011 at 5:50

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

Original comment by dor...@gmail.com on 29 Sep 2011 at 11:03

GoogleCodeExporter commented 9 years ago 
Finally got around to trying 1.3.3c and it's working.. brilliant, thanks!

Original comment by meyer...@gmail.com on 26 Oct 2011 at 11:50

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Configuration file, please?

Original comment by corbinrs...@gmail.com on 23 Nov 2011 at 8:38

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Since the pattern says *.js it seems a reasonable assumption.

Original comment by corbinrs...@gmail.com on 23 Nov 2011 at 10:13

GoogleCodeExporter commented 9 years ago 
This bug comes back in 1.3.4-a and it works fine in 1.3.3-d.

Original comment by too...@gmail.com on 24 Feb 2012 at 9:29

GoogleCodeExporter commented 9 years ago 
Please provide a configuration file.

Original comment by corbinrs...@gmail.com on 24 Feb 2012 at 9:33

GoogleCodeExporter commented 9 years ago 
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.<init>(FileInputStream.java:120)
    at java.io.FileInputStream.<init>(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...

Original comment by meyer...@gmail.com on 19 Mar 2012 at 2:33

GoogleCodeExporter commented 9 years ago 
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)

Original comment by jorn.veg...@gmail.com on 22 Mar 2012 at 9:59

GoogleCodeExporter commented 9 years ago 
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.

Original comment by damon.default on 12 Apr 2012 at 2:02

GoogleCodeExporter commented 9 years ago 
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.

Original comment by meyer...@gmail.com on 30 Jun 2012 at 5:00

GoogleCodeExporter commented 9 years ago 
I see this issue in 1.3.4.b.

Original comment by prashant...@gmail.com on 20 Aug 2012 at 8:19

GoogleCodeExporter commented 9 years ago 
Can still reproduce on 1.3.5 on OS X

Original comment by fritzthe...@gmail.com on 12 Nov 2012 at 5:45

GoogleCodeExporter commented 9 years ago 
Also cannot use absolute paths - the current path is prepended  to anything 
passed in.

Gosh this has been going on for ages

Original comment by fritzthe...@gmail.com on 12 Nov 2012 at 5:47

GoogleCodeExporter commented 9 years ago 
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.

Original comment by meyer...@gmail.com on 12 Nov 2012 at 6:51

GoogleCodeExporter commented 9 years ago 
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?

Original comment by kre...@gmail.com on 22 Nov 2012 at 11:36

GoogleCodeExporter commented 9 years ago 
still an issue for 1.3.5. Tested on Windows 7

Original comment by ing.karl...@gmail.com on 27 Feb 2013 at 11:57