Optimizing WSImport for Multiple WSDLs with Common Types

Question

I am working on a fairly large WS project involving more than 20 different WebServices. These webservices, while independent from each other, share a sizable set of common types. We are using wsimport as an ant target in our build script to generate the proxy classes.

Problem: As the number of our WS(and corresponding WSDLs) has increased, we noticed that the build times for our proxy classes has been climbing up pretty steep. Upon further investigation(and profiling), we found out that a huge chunk of the build time was being spent by wsimport on repeatedly generating the common types. It has gotten to a point that generating, compiling and packaging these proxy classes and their common types are taking around 15-20 mins. This is a problem for us and we are looking for ways to trim down the build time.

Question: Is there a way to only generate the common types once? I've looked into some solutions found by googling. One involved writing a WSDL accumulator which parses the WSDLs and combines them into a single WSDL so wsimport is only called once. Another one hinted at using episode files but further investigation only yielded that there were problems with using that approach.

Note: I have seen some older similar questions but none of them had any answers.

wsimport multiple generated wsdl's

How can I tell wsimport that separate WSDL files are referring to the same object classes?

Roomful

have u tried -keep option ? – Selfloading

You won't be able to do it.... The wsdl accumlator was your best bet, but you don't like it, you can also use bindings to skip generation for common types on subsequents wsdl. The point is that there is no advantage in generating artifacts on build every time... Just keep the generated classes as sources (in a separate jar or not, as you prefer). – Agapanthus

Answer 1

First of all I would use apache cxf to do that build as it can handle multiple WSDLs at the same time and is much more modern. It will be much more efficient and generate better classes. Second of all I would stop worrying about it unless the WSDL files are changing a lot. Instead i would put them into a separate artifact and build them once and then import them into the project as their own artifact. The only thing non-generated in that archive should be test code to test endpoints. As for the build, the Maven plugin config i have used with great success is pasted below.

      <plugin>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-codegen-plugin</artifactId>
    <version>${apache.cxf.version}</version>
    <executions>
      <execution>
        <id>generate-sources</id>
        <phase>generate-sources</phase>
        <configuration>
          <sourceRoot>${project.build.directory}/generated-sources/</sourceRoot>
          <defaultOptions>
            <catalog>${wsdlDir}/jax-ws-catalog.xml</catalog>
            <bindingFiles>
              <bindingFile>${wsdlDir}/jaxb-bindings.xml</bindingFile>
              <bindingFile>${wsdlDir}/jaxws-bindings.xml</bindingFile>
            </bindingFiles>
            <noAddressBinding>true</noAddressBinding>
            <extraargs>
              <extraarg>-client</extraarg>
              <extraarg>-xjc-Xbug671</extraarg>-->
              <extraarg>-xjc-mark-generated</extraarg>
            </extraargs>
          </defaultOptions>
          <wsdlOptions>
            <wsdlOption>
              <wsdl>${wsdlDir}/cis.wsdl</wsdl>
            </wsdlOption>
          </wsdlOptions>
        </configuration>
        <goals>
          <goal>wsdl2java</goal>
        </goals>
      </execution>
    </executions>
    <dependencies>
      <dependency>
        <groupId>org.apache.cxf.xjcplugins</groupId>
        <artifactId>cxf-xjc-bug671</artifactId>
        <version>${apache.cxf.xjc.version}</version>
      </dependency>
    </dependencies>
  </plugin>

This is set up to generate from only one WSDL but one could easily append more WSDLs and I have done so in other circumstances.

Thesda