3.1. Compiling multiple WSDLs that share a common schema
Occasionally, a server will expose multiple services that share common schema types. Perhaps the "common schema types" are from an industry-standard schema, or perhaps the server was developed by a Java-first web service toolkit and the services all use the same Java classes as parameter/return values. When compiling such a WSDL, it's desirable for the shared portion to produce the same Java classes to avoid duplicates. There are two ways to do this.
The easy way is for you to compile all the WSDLs into the same package:
$ wsimport -p org.acme.foo first.wsdl $ wsimport -p org.acme.foo second.wsdl
The Java classes that correspond to the common part will be overwritten multiple times, but since they are identical, in the end this will produce the desired result. If the common part is separated into its own namespace, you can use a JAXB customization so that the common part will go to the overwritten package while everything else will get its own package.
$ cat common.jaxb <bindings xmlns="http://java.sun.com/xml/ns/jaxb" version="2.1"> <bindings scd="x-schema::tns" xmlns:tns="http://common.schema.ns/"> <schemaBindings> <package name="org.acme.foo.common" /> </schemaBindings> </bindings> </bindings> $ wsimport -p org.acme.foo.first first.wsdl -b common.jaxb $ wsimport -p org.acme.foo.second second.wsdl -b common.jaxb
You can also compile the schema upfront by xjc, then use its episode file when later invoking wsimport. For this to work, the common schema needs to have a URL that you can pass into xjc. If the schema is inlined inside the WSDL, you'll have to pull it out into a separate file.
$ xjc -episode common.episode common.xsd $ wsimport wsdl-that-uses-common-schema.wsdl -b common.episode
This will cause wsimport to refer to classes that are generated from XJC earlier.
For more discussion on this, please see this forum thread.