Optimización de WSImport para WSDL múltiples con tipos comunes

Question

Estoy trabajando en un proyecto de WS bastante grande que involucra más de 20 servicios web diferentes. Estos servicios web, aunque son independientes entre sí, comparten un conjunto considerable de tipos comunes. Estamos utilizando wsimport como un objetivo ant en nuestro script de compilación para generar las clases de proxy.

Problema: A medida que el número de WS (y WSDL correspondientes) ha aumentado, notamos que los tiempos de compilación para nuestras clases proxy han ido subiendo bastante. Tras una mayor investigación (y perfilación), descubrimos que wsimport estaba gastando una gran parte del tiempo de compilación en la generación repetida de los tipos comunes. Ha llegado a un punto en el que la generación, compilación y empaquetado de estas clases proxy y sus tipos comunes demoran entre 15 y 20 minutos. Este es un problema para nosotros y estamos buscando formas de recortar el tiempo de compilación.

Pregunta: ¿Hay alguna manera de generar solo los tipos comunes una vez? He investigado algunas soluciones que se encuentran en Google. Una implicaba escribir un acumulador WSDL que analiza los WSDL y los combina en un único WSDL para que wsimport solo se llame una vez. Otro aludió al uso de archivos de episodios, pero una investigación posterior solo arrojó que había problemas con el uso de ese enfoque.

Nota: He visto algunas preguntas similares anteriores, pero ninguna de ellas tenía ninguna respuesta.

wsimport multiple generated wsdl's

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

Answer 1

En primer lugar me gustaría utilizar Apache CXF hacer que se acumulan, ya que puede manejar múltiples WSDL al mismo tiempo y es mucho más moderna. Será mucho más eficiente y generará mejores clases. En segundo lugar, dejaría de preocuparme a menos que los archivos WSDL estén cambiando mucho. En cambio, los colocaría en un artefacto separado y los construiría una vez y luego los importaría al proyecto como su propio artefacto. Lo único que no se ha generado en ese archivo debe ser el código de prueba para probar los puntos finales. En cuanto a la construcción, la configuración del complemento Maven que he utilizado con gran éxito se pega a continuación.

 <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> 

Esto está configurado para generar a partir de una sola WSDL, pero uno podría fácilmente agregar más WSDL y lo han hecho en otras circunstancias.