On Mon, Apr 5, 2010 at 7:13 AM, Tim Williams <william...@gmail.com> wrote: > On Mon, Apr 5, 2010 at 7:04 AM, Tim Williams <william...@gmail.com> wrote: >> On Mon, Apr 5, 2010 at 6:43 AM, Gav... <ga...@16degrees.com.au> wrote: >>> >>> >>>> -----Original Message----- >>>> From: Tim Williams [mailto:william...@gmail.com] >>>> Sent: Monday, 5 April 2010 7:51 PM >>>> To: dev@forrest.apache.org >>>> Subject: Re: forrest-sample-2 FAILED and build test failed: Could not >>>> resolve locationmap location >>>> >>>> On Mon, Apr 5, 2010 at 5:22 AM, Gav... <ga...@16degrees.com.au> wrote: >>>> > >>>> > >>>> >> -----Original Message----- >>>> >> From: Tim Williams [mailto:william...@gmail.com] >>>> >> Sent: Friday, 2 April 2010 11:13 PM >>>> >> To: dev@forrest.apache.org >>>> >> Subject: Re: forrest-sample-2 FAILED and build test failed: Could >>>> not >>>> >> resolve locationmap location >>>> >> >>>> >> On Fri, Apr 2, 2010 at 8:22 AM, Tim Williams <william...@gmail.com> >>>> >> wrote: >>>> >> > On Thu, Apr 1, 2010 at 3:27 AM, David Crossley >>>> <cross...@apache.org> >>>> >> wrote: >>>> >> >>> Automated build for forrest-sample-2 FAILED >>>> >> >>> [java] >>>> >> >>> [java] >>>> >> >>> [java] X [0] >>>> linkmap.html >>>> >> BROKEN: Could not resolve locationmap location. >>>> >> >> >>>> >> >> >>>> >> >> I get that same error doing 'build.sh test' locally. >>>> >> >> >>>> >> >> The build of this Dispatcher sample were okay on the >>>> >> >> zone server before today. >>>> >> > >>>> >> > I'm getting the same thing. It looks like a mounted locationmap >>>> >> can't >>>> >> > be resolved but it appears to be dispatcher-related code. I don't >>>> >> > know that code at all but a quick look seems like the resolver >>>> field >>>> >> > in the child class (RecursiveDirectoryTraversalAction) is hiding >>>> the >>>> >> > intended resolver in the parent class (AbstractTraversal). Can >>>> you >>>> >> > comment out the child class' resolver field and see if that helps? >>>> >> It >>>> >> > seems to get me past that one but then introduces tons of other >>>> >> > "Invalid byte 1 of 1-byte UTF-8 sequence" errors. The timing >>>> seems >>>> >> > right too, it would have been introduced with r929463. >>>> >> >>>> >> I went ahead and applied that because I feel sure that's the right >>>> >> thing to do. I'm now getting errors like: >>>> >> >>>> >> [Fatal Error] :6:25: Invalid byte 1 of 1-byte UTF-8 sequence. >>>> >> X [0] linkmap.pdf BROKEN: >>>> Invalid >>>> >> byte 1 of 1-byte UTF-8 sequence. >>>> >> >>>> >> ... for every pdf file. I don't have time to look into that one >>>> right >>>> >> now though, can someone see if they get the same? >>>> > >>>> > Yes, I am getting it too, but here we are again, a Windows only bug >>>> it >>>> > seems. I don’t get this on any linux box - which is why our zone >>>> doesn’t >>>> > complain. >>>> >>>> Actually, I'm on a Mac. >>> >>> fine, cant help then. >> >> Thanks Gav, >> You may have, I think the default encoding on a Mac isn't utf-8 >> either. I wonder if our source docs which claim utf-8 encoding, >> aren't? When I get home I'll try to open them in a text editor and >> explicitly save one of the known failing docs with utf-8 encoding and >> see if that helps. Unless, of course, someone happens to have time to >> do this test sooner:) > > Firefox does think that my random sampling of content from our svn are > ISO-8859-1 encoded and not UTF-8 (which the xml declaration claims) - > this may be the problem?
I tested my hunch last night to no avail. Must be something else... --tim
