Sorry, I meant URI in the RFC sense, not the Java class. I don't think
in this case anything is gained by using the URL object to construct a
URI object because the classloader should always produce well-formed
URLs with properly encoded paths. At no point are we attempting to
decode it.
Please try both versions; the output should be identical.
On 18/04/12 10:45, Brett Walker wrote:
> Ben,
>
> Should the line be:
>
> String schemaLocation =
> TestConfiguration.class.getResource("test.xsd").toURI().toString();
>
> since getResource() return a URL. You said that schemaLocation should be a
> URI.
>
> Brett
> ________________________________________
> From: Ben Caradoc-Davies [[email protected]]
> Sent: Wednesday, 18 April 2012 12:43 PM
> To: Brett Walker
> Cc: [email protected]; Justin Deoliveira
> Subject: Re: [Geotools-devel] GML3EncodingTest Failing
>
> Brett,
>
> the schemaLocation should be a URI not a file path. Try:
>
> String schemaLocation =
> TestConfiguration.class.getResource("test.xsd").toString();
>
> If this resolves your build failure, please create a Jira issue in the
> GeoTools xsd-gml component (the default assignee should be Justin
> Deoliveira).
>
> Note that the right way to perform File<->URL conversions in this
> project is to use DataUtilities.fileToURL and DataUtilities.urlToFile,
> as I indicated below. No one in this project should a bare
> URLDecoder.decode on a file path without a very good reason why they
> cannot use DataUtilities. But this is not the problem here as the raw
> classpath resource URL should be correct in this case.
>
> Kind regards,
> Ben.
>
> On 18/04/12 10:18, Brett Walker wrote:
>> Hi Ben,
>>
>> I have got around the initial "c:" protocol issue by doing the following
>> change to GML3EncodingTest:
>>
>> 124: String schemaLocation = new
>> File(TestConfiguration.class.getResource("test.xsd").getFile()
>> 125: .getAbsolutePath();
>>
>> to
>>
>> 124: String schemaLocation = new
>> File(URLDecoder.decode(TestConfiguration.class.getResource("test.xsd")
>> 125: .getFile())).getAbsolutePath();
>>
>> but I am still getting the GML3EncodingTest failing. It is failing a JUnit
>> assertTrue on line 173 of the modified file. I'm currently looking into this
>> issue. No idea as to the cause yet. Help as to the cause would be greatfuly.
>>
>> Brett
>> ________________________________________
>> From: Ben Caradoc-Davies [[email protected]]
>> Sent: Wednesday, 18 April 2012 12:06 PM
>> To: Brett Walker
>> Cc: [email protected]; Rini Angreani
>> Subject: Re: [Geotools-devel] GML3EncodingTest Failing
>>
>> (1) Rini uses Windows 7. Rini, do you see Brett's error?
>>
>> (2) Brett, please try a recent Java 6 (latest update is 31). It is
>> possible that there is a Windows 7 bug in update 24; however, I didn't
>> see anything relevant in the release notes.
>>
>> (3) Any build failure in a path with spaces is a bug and should be
>> reported in Jira. I always build in a path with spaces to detect these
>> failures, both locally and on a buildbot (both Linux). These bugs are a
>> proxy for all manner of file path corruption caused by failure to use
>> DataUtilities, resulting in special and international characters being
>> corrupted. Most developers will be aware of my nagging on this issue.
>> Here is the policy:
>> http://docs.geotools.org/latest/developer/conventions/code/url.html
>>
>> Looks like a bug, with "c:" ending up in a URL.
>>
>> Kind regards,
>> Ben.
>>
>> On 18/04/12 07:39, Brett Walker wrote:
>>> Hi Andre,
>>>
>>> I have just noticed something that might be significant. I need to further
>>> investigate it if it is the cause. You might be able to confirm my
>>> suspisions.
>>>
>>> The path on my Windows 7 machine has a space in the path, before the
>>> subdirectory where geotools-trunk resides. This feature is not on my
>>> Windows XP machine. Is there any recommendation about spaces in the path
>>> names in the developers guide? I have skimmed over it but none the wiser. I
>>> thought you might be able to confirm if this is the cause of my problems.
>>>
>>> I'll look into it further,
>>>
>>> Brett
>>>
>>> ________________________________
>>> From: Brett Walker
>>> Sent: Wednesday, 18 April 2012 9:08 AM
>>> To: Andrea Aime
>>> Subject: RE: [Geotools-devel] GML3EncodingTest Failing
>>>
>>> Hi Andre,
>>>
>>> Your response left me suprised that no developer is using Windows 7, not
>>> one. I'll look further into the cause and report back some findings.
>>> Hopefully a fix, at least some advice on how to progress.
>>>
>>> I was hoping that someone was able to divine something more from the
>>> stacktraces or had seen the problem before. I had gathered that 'C:\' was
>>> being interpreted as the protocol but I was left wondering why. This is
>>> what I will look into it.
>>>
>>> Thanks for your response,
>>>
>>> Brett
>>>
>>> ________________________________
>>> From: [email protected] [[email protected]] On Behalf Of Andrea
>>> Aime [[email protected]]
>>> Sent: Wednesday, 18 April 2012 3:55 AM
>>> To: Brett Walker
>>> Cc: [email protected]; Justin Deoliveira
>>> Subject: Re: [Geotools-devel] GML3EncodingTest Failing
>>>
>>> On Tue, Apr 17, 2012 at 6:31 AM, Brett
>>> Walker<[email protected]<mailto:[email protected]>>
>>> wrote:
>>> HI All,
>>>
>>> I have run into a problem with building geotools from trunk. I don’t
>>> believe that I would be the only one encountering this problem.
>>>
>>> At home mnv –version reports:
>>>
>>> Apache Maven 3.0.4 (r1232337; 2012-01-17 19:44:56+1100)
>>>
>>> Maven home: %APACHE_HOME%\Maven\3.0
>>>
>>> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
>>>
>>> Java home: %JAVA_HOME%\jdk1.6\je
>>>
>>> Default locale: en_AU, platform encoding: Cp1252
>>>
>>> OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"
>>>
>>> The entire maven build (mnv –Dall clean install) passes with no errors.
>>>
>>> At work mnv –version reports:
>>>
>>> Apache Maven 3.0.4 (r1232337; 2012-01-17 19:44:56+1100)
>>>
>>> Maven home: %APACHE_HOME%\Maven\3.0
>>>
>>> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
>>>
>>> Java home: %JAVA_HOME%\jdk1.6\je
>>>
>>> Default locale: en_AU, platform encoding: Cp1252
>>>
>>> OS name: "windows 7", version: "6.1", arch: "amd", family: "windows"
>>>
>>>
>>>
>>> The maven build (mnv –Dall clean install) consistently fails in the
>>> XSD-GML3 module while running the GML3EncodingTest.
>>>
>>>
>>>
>>> During the build a stack trace is printed:
>>>
>>>
>>>
>>> WARNING: Error occured getting schema
>>>
>>> java.net.MalformedURLException: unknown protocol: c
>>>
>>> at java.net.URL.<init>(URL.java:574)
>>>
>>> at java.net.URL.<init>(URL.java:464)
>>>
>>> at java.net.URL.<init>(URL.java:413)
>>>
>>> It seems that something like c:\ is taken as the protocol? I don't believe
>>> any active developer uses
>>> Windows 7 though, I can go as high as Windows XP but you say that there it
>>> works so...
>>>
>>> Cheers
>>> Andrea
>>>
>>
>> --
>> Ben Caradoc-Davies<[email protected]>
>> Software Engineer
>> CSIRO Earth Science and Resource Engineering
>> Australian Resources Research Centre
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> GeoTools-Devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
> --
> Ben Caradoc-Davies<[email protected]>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> GeoTools-Devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Ben Caradoc-Davies <[email protected]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
