Dan,

This particular fault isn't caused by a space in the build path ("C:\Work\cxf").

Jim

On 17/12/2010 14:46, Daniel Kulp wrote:
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 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

Reply via email to