>ant test ... \src_dir_1\ford.gxp not in source path

[Ted Husted]

First, thanks so much for taking the time and effort to open source
GXP!

I checked out the source as a read-only user, and the "jar" target ran
just fine. I tried the "test" target, and, sadly, it exposed an error
"\src_dir_1\ford.gxp not in source path". (Screen log annexed.)

Aside from the "E", there were also a few "F"'s in the test result
matrix. Don't know if one is related to the other nor not.

Am I missing a step in the build process, or is something else wrong?

-Ted.

Screen log:

> ant test
Buildfile: build.xml

init:

compile.compiler:
[javac] Compiling 312 source files to C:\projects\GoogleCode\gxp
\trunk\build
\classes

compile.runtime:
[copy] Copying 1 file to C:\projects\GoogleCode\gxp\trunk\build
\classes
[javac] Compiling 34 source files to C:\projects\GoogleCode\gxp
\trunk\build\
classes

compile.tests:
[copy] Copying 2 files to C:\projects\GoogleCode\gxp\trunk\build
\classes
[javac] Compiling 210 source files to C:\projects\GoogleCode\gxp
\trunk\build
\tests

test:
[junit] .........................................
[junit] ...............................E..........
[junit] .........................................
[junit] ................................F.F.F...F..F..
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........
[junit] Time: 11.672
[junit] There was 1 error:
[junit] 1)
testGetSourceFiles(com.google.gxp.compiler.cli.GxpcFlagsTest)java
.lang.IllegalArgumentException: C:\projects\GoogleCode\gxp\trunk
\src_dir_1\ford.
gxp not in source path
[junit] at
com.google.gxp.compiler.fs.SourcePathFileSystem.<init>(Source
PathFileSystem.java:59)
[junit] at
com.google.gxp.compiler.cli.GxpcFlags.<init>(GxpcFlags.java:9
5)
[junit] at
com.google.gxp.compiler.cli.GxpcFlagsTest.createConfig(GxpcFl
agsTest.java:60)
[junit] at
com.google.gxp.compiler.cli.GxpcFlagsTest.createConfig(GxpcFl
agsTest.java:64)
[junit] at
com.google.gxp.compiler.cli.GxpcFlagsTest.testGetSourceFiles(
GxpcFlagsTest.java:142)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
sorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
[junit] There were 5 failures:
[junit] 1)
testGetLastModified(com.google.gxp.compiler.fs.SystemFileSystemTe
st)junit.framework.ComparisonFailure: null expected:<[/]tmp
\idontexist> but was:
<[C:\]tmp\idontexist>
[junit] at
com.google.gxp.compiler.fs.SystemFileSystemTest.fileRef(Syste
mFileSystemTest.java:93)
[junit] at
com.google.gxp.compiler.fs.SystemFileSystemTest.testGetLastMo
dified(SystemFileSystemTest.java:67)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
sorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
[junit] 2)
testToFilename(com.google.gxp.compiler.fs.SystemFileSystemTest)ju
nit.framework.ComparisonFailure: null expected:<[/]foobar> but
was:<[\]foobar>
[junit] at
com.google.gxp.compiler.fs.SystemFileSystemTest.testToFilenam
e(SystemFileSystemTest.java:139)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
sorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
[junit] 3)
testParseFilename(com.google.gxp.compiler.fs.SystemFileSystemTest
)junit.framework.ComparisonFailure: null expected:<[C:\projects
\GoogleCode\gxp\t
runk\]foobar> but was:<[/C:/projects/GoogleCode/gxp/trunk/]foobar>
[junit] at
com.google.gxp.compiler.fs.SystemFileSystemTest.testParseFile
name(SystemFileSystemTest.java:128)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
sorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
[junit] 4)
testOpenWriter(com.google.gxp.compiler.fs.SystemFileSystemTest)ju
nit.framework.ComparisonFailure: null expected:<[/]tmp\output1.txt>
but was:<[C:
\]tmp\output1.txt>
[junit] at
com.google.gxp.compiler.fs.SystemFileSystemTest.fileRef(Syste
mFileSystemTest.java:93)
[junit] at
com.google.gxp.compiler.fs.SystemFileSystemTest.assertOpenWri
terWorks(SystemFileSystemTest.java:99)
[junit] at
com.google.gxp.compiler.fs.SystemFileSystemTest.testOpenWrite
r(SystemFileSystemTest.java:57)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
sorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
[junit] 5)
testToRelativeFilename(com.google.gxp.compiler.fs.SystemFileSyste
mTest)junit.framework.ComparisonFailure: null expected:<[/]z> but
was:<[\x\y\x\y
\]z>
[junit] at
com.google.gxp.compiler.fs.SystemFileSystemTest.testToRelativ
eFilename(SystemFileSystemTest.java:151)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
sorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
[junit]
[junit] FAILURES!!!
[junit] Tests run: 542, Failures: 5, Errors: 1
[junit]

BUILD FAILED
C:\projects\GoogleCode\gxp\trunk\build.xml:177: Java returned: 1

Total time: 56 seconds
C:\projects\GoogleCode\gxp\trunk>

[Laurence Gonsalves]

Hmmm... It looks like we've got some Windows compatibility issues in
our file system abstraction layer (com.google.gxp.compiler.fs). I'll
take a look at it tomorrow, and hopefully we can get a fix out soon.

Thanks for reporting this!

[Al Sutton]

It looks like FileRef is designed for Unix environments. Things like
isAncestorOf relies on file paths starting with / and using / as the
path seperator.

Al.

[Laurence Gonsalves]

FileRef has an internal representation that uses "/" as a path
separator (ie: the internal representation uses "UNIX-like"
conventions), but SystemFileSystem and its FileStore are supposed to
convert between the local system's conventions and this internal
representation. It was designed to be portable in principle, but we
don't regularly run the tests on Windows. I'm guessing the problem is
in the conversion process.

[Al Sutton]

Thanks for the explanation.

First off I'm wondering if doing things that way provides any
advantages? If the portability components were rolled into where they
are needed it would make the code easier to understand and possibly
easier to debug. Do you know what the design motivator was behind doing
file name munging?, from what I've seen in the past I would take a shot
that the original devs were Unix to guys the core and wanted a way to
bring all pathnames into their comfort zone ;).

I've pasted the "ant test" output from Windows below, and all of the
failures appear to stem from filenames not being brought into the
internal format (the failure messages seem make that clear).

The error is a bit more difficult to track down (mainly because my
regexp isn't as good as it should be). The problem is in the call in the
following line from GxpcFlagsTest;

config = createConfig(
"--source", "src_dir_1:src_dir_2",
"src_dir_1" + SLASH + "ford.gxp",
"src_dir_1" + SLASH + "zaphod.gxp",
"src_dir_2" + SLASH + "trillian.gxp");

From what I can see the src_dir_1 and src_dir_2 are not being expanded
and so you end up with things like
"[path_to_svn_checkout]/src_dir_1/[filename]". Given that I can run ant
test on a Linux VMWare instance and it doesn't fail (and I've tried with
and without spaces in the path name), I'm guessing that somewhere a
regex and/or replacement isn't scanning past the /C:/ which starts
windows paths. I would look into it a bit further, but, alas, the day
job calls....

Al.

>> Test output <<

test:
[junit] .........................................
[junit] ...............................E..........
[junit] .........................................
[junit] ................................F.F.F...F..F..
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................
[junit] .........................................

[junit] ...........
[junit] Time: 11.08

[junit] There was 1 error:
[junit] 1)
testGetSourceFiles(com.google.gxp.compiler.cli.GxpcFlagsTest)java

.lang.IllegalArgumentException: C:\Users\Al
Sutton\Documents\Projects\Workspaces
\GXP\gxp\src_dir_1\ford.gxp not in source path

)junit.framework.ComparisonFailure: null expected:<[C:\Users\Al
Sutton\Documents
\Projects\Workspaces\GXP\gxp\]foobar> but was:<[/C:/Users/Al
Sutton/Documents/Pr
ojects/Workspaces/GXP/gxp/]foobar>

[junit] Tests run: 544, Failures: 5, Errors: 1
[junit]

[musachy]

I attached a patch for SystemFileSystemTest here:

http://code.google.com/p/gxp/issues/detail?id=1

I am rebuilding my linux box, so I only tested on windows, not sure if
it will break on a unix machine(it shouldn't).

musachy

On Jul 27, 8:12 pm, Laurence Gonsalves <laurence.gonsal...@gmail.com>
wrote:

[musachy]

This will fix it:

Index: java/test/com/google/gxp/compiler/cli/GxpcFlagsTest.java
===================================================================
--- java/test/com/google/gxp/compiler/cli/GxpcFlagsTest.java (revision
77)
+++ java/test/com/google/gxp/compiler/cli/GxpcFlagsTest.java (working
copy)
@@ -140,7 +140,7 @@

// Sources specified, with source path.
config = createConfig(
- "--source", "src_dir_1:src_dir_2",
+ "--source", "src_dir_1" + File.pathSeparator + "src_dir_2",

"src_dir_1" + SLASH + "ford.gxp",
"src_dir_1" + SLASH + "zaphod.gxp",
"src_dir_2" + SLASH + "trillian.gxp");

musachy

> read more »

[Laurence Gonsalves]

On Jul 29, 12:39 am, Al Sutton <al.sut...@alsutton.com> wrote:
> Thanks for the explanation.
>
> First off I'm wondering if doing things that way provides any
> advantages? If the portability components were rolled into where they
> are needed it would make the code easier to understand and possibly
> easier to debug. Do you know what the design motivator was behind doing
> file name munging?, from what I've seen in the past I would take a shot
> that the original devs were Unix to guys the core and wanted a way to
> bring all pathnames into their comfort zone ;).

I'm the developer behind the code in question. :-)


The file system abstraction layer is also used to make the code easier
to test (a lot of our tests use an "in memory" virtual file system),
and we also use a virtual file system for dealing with source paths.

As for using an internal representation rather than the native
system's representation, the reason for this was just to centralize
all of the platform specific quirks so that the rest of the code
wouldn't have to deal with it. I admit that the fact that I work
mostly on UNIX environments was probably an influence on using "/" as
a delimiter for the internal representation, but it was also because
it doesn't require escaping in Java's string literals. I almost used
arrays or Lists of path components rather than delimited strings,
actually.

> I've pasted the "ant test" output from Windows below, and all of the
> failures appear to stem from filenames not being brought into the
> internal format (the failure messages seem make that clear).
>
> The error is a bit more difficult to track down (mainly because my
> regexp isn't as good as it should be). The problem is in the call in the
> following line from GxpcFlagsTest;
>

...

>
> From what I can see the src_dir_1 and src_dir_2 are not being expanded
> and so you end up with things like
> "[path_to_svn_checkout]/src_dir_1/[filename]". Given that I can run ant
> test on a Linux VMWare instance and it doesn't fail (and I've tried with
> and without spaces in the path name), I'm guessing that somewhere a
> regex and/or replacement isn't scanning past the /C:/ which starts
> windows paths. I would look into it a bit further, but, alas, the day
> job calls....

Thanks for taking a look into this. My Windows machines have been on
the fritz the last couple of days, but I just got one working again,
so hopefully I can reproduce the problem and get it fixed soon.

[Laurence Gonsalves]

Thanks for both of your patches! I'll try them out, and hopefully we
can get them merged into svn soon.

> ...
>
> read more »

[Laurence Gonsalves]

Okay, svn has been updated with a fix. Thanks everyone for reporting
the problem and helping with the fix.


On Jul 29, 6:56 pm, Laurence Gonsalves <laurence.gonsal...@gmail.com>
wrote:

> ...
>
> read more »