Hi I've tried to fix most of the build failures on Windows (with the source being checked out to the path containing spaces) [1].
The systests/ws-spec test failures seem to be transient, possibly caused by previous test failures. The only test I could not fix in the wsdlto/test module [2] is CodeGenBugTest.testCXF3105 [3], which is the very last test in the CodeGenBugTest. Can someone else give it a try ? Note that both getLocation() calls in that test already rely on the proper toURI().getPath() fix, but File f = new File(output, "org/apache/cxf/testcase/cxf3105/Login.java"); assertTrue(f.exists()); fails. It seems like the problem is inside WSDLToJava, I recall some JAXB warning being generated - check it again next time I'm working in Windows Cheers, Sergey [1] https://hudson.apache.org/hudson/job/CXF-trunk-windows/lastBuild/testReport/ [2] https://hudson.apache.org/hudson/job/CXF-trunk-windows/org.apache.cxf$cxf-tools-wsdlto-test/5/testReport/ [3] http://svn.apache.org/repos/asf/cxf/trunk/tools/wsdlto/test/src/test/java/org/apache/cxf/tools/wsdlto/jaxws/CodeGenBugTest.java On Fri, Dec 17, 2010 at 3:43 PM, Gary Gregory <[email protected]>wrote: > Hi All: > > The problems I've seen in general with spaces in path names is when code > tries to use a URL path without converting the %20 and other %'s to proper > characters. > > This is no good: aURL.getFile() orr in general anything URL provides as a > "file" or for use with a java.io.File > This is ok: aURL: aURL.toURI().getPath() > > You can the use the result as a File. > > Gary > > > -----Original Message----- > > From: Daniel Kulp [mailto:[email protected]] > > Sent: Friday, December 17, 2010 06:47 > > To: [email protected] > > Cc: Jim Talbut > > Subject: Re: Failure building latest trunk > > > > > > I actually did start adding a Windows job to Hudson, but there are a > > bunch of test failues with it: > > > > https://hudson.apache.org/hudson/view/A-F/view/CXF/job/CXF-trunk- > > windows/lastBuild/testReport/ > > > > The job was setup with putting the checkout location (and the .m2 > > repo) into a directory with spaces (to test that scenario since, for > > some reason, windows people like spaces in dirs) so some of the > > tests may be failing for that reason. I just haven't had time to > really > > look into any of them, especially since I don't even have a windows > > machine. > > > > At some point, I'd like to also get some hudson builds on Solaris > > and also on Linux using the IBM JDK. Right now, a bunch of > > tests fail with the 1.6 IBM JDK as well. > > > > If anyone is looking for some places to start contributing, there's > > a couple good ones. :-) > > > > Dan > > > > > > > > On Friday 17 December 2010 5:14:29 am Jim Talbut wrote: > > > Hi, > > > > > > On revision 1050333 building on Windows Vista 64bit, java version > > > 1.6.0_21, Maven 2.2.1, I hit the following error: > > > > > > 17-Dec-2010 09:09:05 > > > org.apache.cxf.tools.validator.internal.WSDLRefValidator > > > collectValidationPointsForBindings > > > SEVERE: {http://child/}Binding <http://child/%7DBinding> is not > correct, please check that the > > > correct namespace is being used > > > > > > WSDLToJava Error: Thrown by JAXB: A class/interface with the same name > > > "org.apache.cxf.testcase.cxf3105.LoginResponse" is already in use. Use > a > > > class customization or the -autoNameResolution option to resolve this > > > conflict. > > > > > > Tests run: 63, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 21.963 > > > sec <<< FAILURE! > > > testCXF3105(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest) Time > > > elapsed: 0.078 sec <<< FAILURE! > > > java.lang.AssertionError: > > > at org.junit.Assert.fail(Assert.java:91) > > > at org.junit.Assert.assertTrue(Assert.java:43) > > > at org.junit.Assert.assertTrue(Assert.java:54) > > > at > > > > org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest.testCXF3105(CodeGenBugTest > > > .java:1148) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > > at > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 > > > 9) at > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp > > > l.java:25) at java.lang.reflect.Method.invoke(Method.java:597) > > > > > > > > > > > > Looking at the wsdl I wonder if this is caused by a case insensitivity > > > issue on Windows? > > > > > > Jim > > > > -- > > Daniel Kulp > > [email protected] > > http://dankulp.com/blog >
