maven-cxf-codegen-plugin-wsdl-to-java

From：http://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html

 

CXF includes a Maven plugin which can generate java artifacts from WSDL. Here is a simple example:

<plugin>

    <groupId>org.apache.cxf</groupId>

    <artifactId>cxf-codegen-plugin</artifactId>

    <version>${cxf.version}</version>

    <executions>

        <execution>

            <id>generate-sources</id>

            <phase>generate-sources</phase>

            <configuration>

                <sourceRoot>${project.build.directory}/generated/cxf</sourceRoot>

                <wsdlOptions>

                    <wsdlOption>

                        <wsdl>${basedir}/src/main/resources/myService.wsdl</wsdl>

                    </wsdlOption>

                </wsdlOptions>

            </configuration>

            <goals>

                <goal>wsdl2java</goal>

            </goals>

        </execution>

    </executions>

</plugin>

In this example we're running the wsdl2java goal in the generate-sources phase. By running mvn generate-sources, CXF will generate artifacts in the <sourceRoot> directory that you specify. Each <wsdlOption> element corresponds to a WSDL that you're generated artifacts for. The WSDL location is specified via the <wsdl> option. Following Maven standard directory layout, if you're planning on packaging the WSDL in the JAR you're creating you'll want the WSDL above in /src/main/resources/ (alternatively in a subfolder underneath it if desired to avoid placing resources in the root of a JAR); else use the /src/main/config folder to keep the WSDL out of the JAR.

The following example shows some customization options. By default, the codegen plugin follows the Maven convention of "target/generated-sources/cxf" for the output folder for the generated classes. You can override this value using <sourceRoot> as shown below, but note this is usually not necessary, the default is fine for most people and can make it easier for some IDE's to detect the generated source code. Other configuration arguments can be included inside the <wsdlOption> element. These pass arguments to the tooling and correspond to the options outlined on the WSDL to Java page.

...

<configuration>

    <sourceRoot>${project.build.directory}/generated-code/mywebservice</sourceRoot>

    <wsdlOptions>

    <wsdlOption>

        <wsdl>${basedir}/src/main/resources/wsdl/myService.wsdl</wsdl>

                <!-- you can set the options of wsdl2java command by using the <extraargs> -->

                <extraargs>

                    <extraarg>-impl</extraarg>

                    <extraarg>-verbose</extraarg>

                </extraargs>

    </wsdlOption>

    </wsdlOptions>

</configuration>

...

See this blog entry for a full service and client example that uses the cxf-codegen-plugin.

Example 1: Passing in a JAX-WS Binding file

<configuration>

  <wsdlOptions>

    <wsdlOption>

      <wsdl>${basedir}/src/main/resources/wsdl/myService.wsdl</wsdl>

      <bindingFiles>

        <bindingFile>${basedir}/src/main/resources/async_binding.xml</bindingFile>

      </bindingFiles>

    </wsdlOption>

  </wsdlOptions>

</configuration>

In this example we're specifying that we want CXF to use our JAX-WS binding file. Binding files are a way to customize the output of the artifacts that CXF generates. For instance, it allows you to change the package name CXF uses.

Example 2: Specify the data binding

<configuration>

  <wsdlOptions>

    <wsdlOption>

      <wsdl>${basedir}/src/main/resources/wsdl/myService.wsdl</wsdl>

      <extraargs>

        <extraarg>-databinding</extraarg>

        <extraarg>jibx</extraarg>

      </extraargs>

    </wsdlOption>

  </wsdlOptions>

</configuration>

In this example we're specifying that we want CXF to use our data binding jibx. You can also using the data binding of xmlbeans, domsources, sdo etc.

Example 3: Specifying a service to generate artifacts for

<configuration>

  <wsdlOptions>

    <wsdlOption>

      <wsdl>${basedir}/src/main/resources/wsdl/myService.wsdl</wsdl>

      <serviceName>MyWSDLService</serviceName>

    </wsdlOption>

  </wsdlOptions>

</configuration>

In this example we're specifying that we only want to generate artifacts for the service named "MyWSDLService" in the WSDL.

To avoid copy/paste in multiple <wsdlOption> you can also declare a <defaultOption> element.

Example 4: Using defaultOption to avoid repetition

<configuration>

  <defaultOptions>

      <bindingFiles>

          <bindingFile>${basedir}/src/main/jaxb/bindings.xml</bindingFile>

      </bindingFiles>

      <noAddressBinding>true</noAddressBinding>

  </defaultOptions>

  <wsdlOptions>

      <wsdlOption>

          <wsdl>${basedir}/src/main/resources/wsdl/myService.wsdl</wsdl>

          <serviceName>MyWSDLService</serviceName>

      </wsdlOption>

      <wsdlOption>

          <wsdl>${basedir}/src/main/resources/wsdl/myOtherService.wsdl</wsdl>

          <serviceName>MyOtherWSDLService</serviceName>

      </wsdlOption>

  </wsdlOptions>

</configuration>

<defaultOption> and <wsdlOption> correspond to the options outlined on the WSDL to Java page, you may look athttp://svn.apache.org/repos/asf/cxf/trunk/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/Option.java for a more detailed description of those parameters.

At least, you can declare a common wsdlRoot folder where you store your WSDL files and use includes/excludes patterns to select the files to get used by the code generator

Example 5: Using wsdlRoot with includes/excludes patterns

<configuration>

  <defaultOptions>

      <bindingFiles>

          <bindingFile>${basedir}/src/main/jaxb/bindings.xml</bindingFile>

      </bindingFiles>

      <noAddressBinding>true</noAddressBinding>

  </defaultOptions>

  <wsdlRoot>${basedir}/src/main/resources/wsdl</wsdlRoot>

  <includes>

      <include>*Service.wsdl</include>

  </includes>

</configuration>

wsdlRoot default value is src/main/resources/wsdl so you may omit this declaration.

Example 6: Loading a wsdl from the maven repository

For CXF 2.3 and latter there is a new config element <wsdlArtifact> which can be used to load a wsdl file from the maven repository.

<configuration>

 <wsdlOptions>

  <wsdlOption>

   <wsdlArtifact>

    <groupId>org.apache.pizza</groupId>

<artifactId>PizzaService</artifactId>

<version>1.0.0</version>

   </wsdlArtifact>

  </wsdlOption>

 </wsdlOptions>

</configuration>

This will load the wsdl /org/apache/pizza/PizzaService-1.0.0.wsdl into your local maven repository and generate java code from it.

Example 7: Using xjc extensions

Standard JAXB command-line customizations can be added via <extraarg> elements, either one per line or comma separated. CXF also offers some JAXB extensions for the code generation. They have to be added as dependencies and then activated by using an extraarg with content -xjc-X<extension id>

artifact id

description

extension id

Fluent API for setters

cxf-xjc-boolean	Adds getters for booleans	boolean
cxf-xjc-bug671	Workaroung for JAXB bug 671	bug671
cxf-xjc-dv	Default value support	dv
cxf-xjc-ts	Adds toString to objects	ts
cxf-xjc-wsdlextension	WsdlExtension support	wsdlextension
jaxb-fluent-api	fluent-api

An example showing attachment of a JAXB binding file and the CXF toString() extension is below:

<plugin>

<groupId>org.apache.cxf</groupId>

<artifactId>cxf-codegen-plugin</artifactId>

<version>${cxf.version}</version>

<executions>

  <execution>

    <id>generate-sources</id>

    <phase>generate-sources</phase>

    <configuration>

      <wsdlOptions>

        <wsdlOption>

          <wsdl>${basedir}/src/main/resources/wsdl/myService.wsdl</wsdl>

          <extraargs>

            <extraarg>-xjc-b,binding.xjb</extraarg>

            <extraarg>-xjc-Xts</extraarg>

          </extraargs>

        </wsdlOption>

      </wsdlOptions>

    </configuration>

    <goals>

      <goal>wsdl2java</goal>

    </goals>

  </execution>

</executions>

<dependencies>

    <dependency>

        <groupId>org.apache.cxf.xjcplugins</groupId>

        <artifactId>cxf-xjc-ts</artifactId>

        <version>${cxf.version}</version>

     </dependency>

</dependencies>

</plugin>

Example 8 - Using JAXB/JAX-WS 2.2 with Java 6

Java 6 includes JAXB/JAX-WS 2.1 API's and a 2.1 implementations. However, sometimes it's desirable to use JAXB or JAX-WS 2.2 instead to obtain various bug fixes and enhancements. Using 2.2 with Java 6 and Maven can be a bit tricky as it requires endorsing the API jars which requires configuration of a bunch of plugins, requires use of "forking", etc... First off, both Surefire and the Compiler plugins need to be setup to point at an endorsed dir:

<pluginManagement>

    <plugins>

        <plugin>

            <groupId>org.apache.maven.plugins</groupId>

            <artifactId>maven-compiler-plugin</artifactId>

            <configuration>

                <compilerArguments>

                   <endorseddirs>${project.build.directory}/endorsed</endorseddirs>

                </compilerArguments>

            </configuration>

        </plugin>

        <plugin>

            <groupId>org.apache.maven.plugins</groupId>

            <artifactId>maven-surefire-plugin</artifactId>

            <configuration>

                <forkMode>once</forkMode>

                <argLine>-Djava.endorsed.dirs=${project.build.directory}/endorsed</argLine>

            </configuration>

         </plugin>

    </plugins>

</pluginManagement>

You will then need to use the maven-dependency-plugin to copy the needed artifacts into the endorsed.dir:

<plugins>

    <plugin>

       <groupId>org.apache.maven.plugins</groupId>

       <artifactId>maven-dependency-plugin</artifactId>

       <executions>

          <execution>

             <phase>generate-sources</phase>

             <goals>

                 <goal>copy</goal>

             </goals>

             <configuration>

                 <artifactItems>

                    <artifactItem>

                       <groupId>javax.xml.bind</groupId>

                       <artifactId>jaxb-api</artifactId>

                       <version>2.2</version>

                    </artifactItem>

                    <artifactItem>

                       <groupId>javax.xml.ws</groupId>

                       <artifactId>jaxws-api</artifactId>

                       <version>2.2</version>

                    </artifactItem>

                  </artifactItems>

                  <outputDirectory>${project.build.directory}/endorsed</outputDirectory>

              </configuration>

           </execution>

       </executions>

    </plugin>

</plugins>

Finally, you need to do similar setup for the CXF Codegen plugin so it picks up the 2.2 API's and runtimes:

<plugin>

    <groupId>org.apache.cxf</groupId>

    <artifactId>cxf-codegen-plugin</artifactId>

    <version>${cxf.version}</version>

    <configuration>

        <fork>once</fork>

        <additionalJvmArgs>-Djava.endorsed.dirs=${project.build.directory}/endorsed</additionalJvmArgs>

        <!-- rest of the normal codegen configuration options -->

    </configuration>

    <dependencies>

        <dependency>

           <groupId>com.sun.xml.bind</groupId>

           <artifactId>jaxb-impl</artifactId>

           <version>2.2</version>

        </dependency>

        <dependency>

           <groupId>com.sun.xml.bind</groupId>

           <artifactId>jaxb-xjc</artifactId>

           <version>2.2</version>

        </dependency>

     </dependencies>

</plugin>

Other configuration options

The cxf-codegen-plugin has some additional configuration options that may be useful:

<fork>false/always/once</fork>	Forks a separate JVM for the code generation
<additionalJvmArgs>....	Additional JVM args set on the forked process if fork is not false
<encoding>UTF-8</encoding>	(new in 2.6.1, requires configuring plugin to use very latest JAXB 2.2 impl jars)