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