Hi Ben, I had success with your suggestion and my suggestion. Which version is more prefferable?
I'm running a complete mvn clean install now I'll create an issue and a patch to resolve the problem, if the mvn clean install passed. Brett ________________________________________ From: Brett Walker Sent: Wednesday, 18 April 2012 12:45 PM To: [email protected] Subject: RE: [Geotools-devel] GML3EncodingTest Failing 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
