And, if I remove the other execution from this particular pom.xml it:
a) Generates the correct java for RefDataService.wsdl
AND
b) Generates java for the other wsdl file in the same location as
RefDataService.wsdl, despite not having an execution for it.
Now I'm really confused.
Jim
On 03/12/2010 15:49, Jim Talbut wrote:
Hi,
Using the cxf-codegen-plugin seems to produce different results to
calling wsdl2java directly (particularly with regard to arguments
passed in).
Example one:
<execution>
<id>generate-service</id>
<phase>generate-sources</phase>
<configuration>
<wsdlOptions>
<wsdlOption>
<wsdl>src/main/resources/wsdl/RefDataService.wsdl</wsdl>
<bindingFiles>
<bindingFile>${basedir}/src/main/resources/wsdl/RefDataServiceBinding.xml</bindingFile>
</bindingFiles>
<extraargs>
<extraarg>-server</extraarg>
<!-- Note that the next two are a pair, without them the path to the
WSDL file gets hardcoded in the Service -->
<extraarg>-wsdlLocation</extraarg>
<extraarg></extraarg>
</extraargs>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
The binding file is supposed to generate java.util.Date for
xsd:dateTime, but the output is still using
javax.xml.datatype.XMLGregorianCalendar.
But if I run the following from a command line:
wsdl2java -b RefDataServiceBinding.xml RefDataService.wsdl
it works correctly.
Example two:
Trying to pass the --exsh argument makes no difference:
<extraarg>-exsh</extraarg>
<extraarg>true</extraarg>
This was using a .Net WCF WSDL file with a lot of parameters needing
to be passed in the SOAP:header -- without exsh the generated code is
unusable.
For this one I ended up generating the code at the command line.
I've tried a few different versions of CXF, this is currently using
2.3.0.
Running with mvn -X turns up the following line (edited to remove path
root):
[DEBUG] Calling wsdl2java with args: [-d,
PATHROOT\target\generated-sources\cxf, -verbose,
file:/PATHROOT/src/main/resources/wsdl/RefDataService.wsdl]
Even the wsdlLocation argument has been lost - though there is another
execution in the same pom.xml that also has a wsdlLocation argument
that IS being passed to wsdl2java.
Does the problem relate to requirin multiple calls to wsdl2java in a
single pom?
Jim