forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: forrest-sample-2 FAILED and build test failed: Could not resolve locationmap location
Date Mon, 05 Apr 2010 11:13:53 GMT
On Mon, Apr 5, 2010 at 7:04 AM, Tim Williams <williamstw@gmail.com> wrote:
> On Mon, Apr 5, 2010 at 6:43 AM, Gav... <gavin@16degrees.com.au> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Tim Williams [mailto:williamstw@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... <gavin@16degrees.com.au> wrote:
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: Tim Williams [mailto:williamstw@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 <williamstw@gmail.com>
>>> >> wrote:
>>> >> > On Thu, Apr 1, 2010 at 3:27 AM, David Crossley
>>> <crossley@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?

--tim

Mime
View raw message