Absolute Paths on Windows fail

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Specify an absolute path in the conf file on Windows (with a leading drive 
letter, e.g. C:/project/src/file.js)
2. Run jstd on Windows

What is the expected output? What do you see instead?
The file path should be resolved correctly. It is, however, interpreted as a 
relative path resulting in a lookup to [baseDir]/C:/project/src/file.js which 
then fails ('pattern doesn't match..')

What version of the product are you using? On what operating system?
1.3.2
1.3.3b

Please provide any additional information below.

PathResolver#resolvePath checks for a leading slash (or rather File.separator). 
On Windows absolute paths don't start with a backslash though but with the 
drive letter.

Original issue reported on code.google.com by mistae...@gmail.com on 5 Oct 2011 at 2:20

[GoogleCodeExporter]

Possible fix: use File#isAbsolute which is platform independent.

  public File resolvePath(String filePath) {
      File file = new File(filePath);
      if(!file.isAbsolute())
        file = new File(basePath, filePath);

The patch also includes test cases for absolute path handling and
fixes for all path related test cases to run on Windows.

Original comment by mistae...@gmail.com on 5 Oct 2011 at 2:27

Attachments:

• windows-path-fixes-all.patch

[GoogleCodeExporter]

Can you fill out http://code.google.com/legal/individual-cla-v1.0.html and let 
me know when you do? After that, I can apply the patch.

Original comment by corbinrs...@gmail.com on 7 Oct 2011 at 10:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Done!

Original comment by mistae...@gmail.com on 8 Oct 2011 at 2:30

[GoogleCodeExporter]

As of r1064

Slated for 1.3.3c

Original comment by corbinrs...@gmail.com on 8 Oct 2011 at 6:56

• Changed state: Fixed

[GoogleCodeExporter]

Absolute paths still fail on OS X. It looks like the mistake is that 
PathResolver.resolve(Set<FileInfo> unresolvedFiles) doesn't call the method 
above. It calls expandFileInfosFromFileInfo which does this:

    for (File basePath : basePaths) {
        File file = new File(basePath, filePath); <-- WRONG, no check for file being absolute.

Tracing it through YAMLParser.parse() calls 
resolvedFilesLoad.addAll(createFileInfos((List<String>) data
        .get("load"), false));
(which despite the name, isn't resolved files)
This then gets passed into new ParsedConfiguration(...)
which then has its resolvePaths(pathResolver, flags) method called
which calls pathResolver.resolve(Set<FileInfo> unresolvedFiles)
which then calls expandFileInfosFromFileInfo() which has this bug.

Original comment by brian.ew...@gmail.com on 26 Apr 2012 at 1:42

[GoogleCodeExporter]

Absolute paths also fail on Linux in 1.3.4.b.
This used to work in 1.3.2.

Original comment by bernd.pa...@gmail.com on 7 Sep 2012 at 6:05