Skip to main contentdfsdf

Vishwanath Krishnamurthi's List: WebServices Resources

  • Complete Tutorials

  • Apr 17, 11

    Explains a maven project setup

    blogs.sun.com/...using_jax_ws_with_maven maven jax-ws

    • Creating the Project and Subprojects

       

      In this sample, you create a main project, that is, a parent  project, named jaxws-maven-sample. The parent project has two  subprojects: HelloService, for the web service, and HelloClient, for the web service client. Here is what the project structure  looks like:

          jaxws-maven-sample (POM Project)
            helloservice (WAR project)
            helloclient (JAR Project)

  • Services Project

  • Apr 17, 11

    jax-ws-commons.java.net/...wsgen-mojo.html maven jax-ws

      • jaxws:wsgen

         

        Full name:

         

        org.codehaus.mojo:jaxws-maven-plugin:1.12:wsgen

         

        Description:

         
        Reads a JAX-WS service endpoint implementation class and generates all of the portable artifacts for a JAX-WS web service.

        Attributes:

         
        • Requires a Maven 2.0 project to be executed.
          •  
        • Requires dependency resolution of artifacts in scope: runtime.
          •  
        • Binds by default to the lifecycle phase: process-classes.

      • An adaptor over wsgen tool

  • Client Project

  • Apr 17, 11

    mojo.codehaus.org/...wsimport-mojo.html maven jax-ws

      • jaxws:wsimport

         

         A Maven 2 plugin which parses wsdl and binding files and produces a corresponding object model based on the JAXWS WsImport parsing engine. 

         

        Mojo Attributes:

           
        • Requires a Maven 2.0 project to execute.
          •  
        • Requires dependency resolution of artifacts in scope: runtime
          •  
        • Automatically executes within the lifecycle phase: generate-sources

  • Apr 17, 11

    "<plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> "

    jax-ws-commons.java.net/...usage.html maven-plugins

    • <plugin>  <groupId>org.codehaus.mojo</groupId>  <artifactId>jaxws-maven-plugin</artifactId>  <executions>  <execution>  <goals>  <goal>wsimport</goal>  </goals>  </execution>  </executions>  <configuration>  <packageName>com.example.myschema</packageName> <!-- The name of your generated source package -->  </configuration>   <!-- if you want to use a specific version of JAX-WS, you can do so like this -->  <dependencies>  <groupId>com.sun.xml.ws</groupId>  <artifactId>jaxws-tools</artifactId>  <version>2.1.1</version>  </dependencies>  </plugin>

  • To explore

  • Apr 17, 11

    "At first i'll advice you using XFire ( http://xfire.codehaus.org ), its
    more user friendly.
    You can just run wsdl generator from cmd line or run your service on
    any webserver and XFire will generate wsdl for you "

    www.velocityreviews.com/...erate-wsdl-from-java-code.html wsdl-generation-strategies

    • At first i'll advice you using XFire ( http://xfire.codehaus.org ), its
       more user friendly.
       You can just run wsdl generator from cmd line or run your service on
       any webserver and XFire will generate wsdl for you
    • Axis generate the WSDL when you deploy the web service !

      • ^ gotto explore that

  • Maven Setup

  • Apr 17, 11

    maven.apache.org/...faq.html maven

    • When Eclipse is not generating source code for you there is a conflict between Maven generating the source code and then Eclipse treating it as compiled code. Typically when generating code using Maven the code ends up in the target/classes directory. This is fine as long as Maven is doing the build. However, if Eclipse is then setup to do the build, when Eclipse performs a clean build all the generated code in target/classes will be removed.

       

      The alternatives typically are to place the generated code in the /src/java directory and allow Maven and Eclipse to treat it the same. However, this leads to a tendency to check generated code into source control, which typically is not appropriate for generated code. Alternatively, it can be placed in some sort of /src/generated or target/generated directory. In Maven2, generated code lives in target/generated-sources, in a manner similiar to generated xdoc's live in target/generated-xdocs. Within the target/generated-sources would be each type of generated code.

       

      By default, the plugin will load as seperate source folders any directory found in ${maven.build.dir}/generated-sources. So, if you generate your mock objects into ${maven.build.dir}/generated-sources/mocks and your wsdl classes into ${maven.build.dir}/generated-sources/wsdl then each of these directories will be mounted as source folders. Note: You must have already created these directories, otherwise the plugin won't know to add them as source folders. Before running maven eclipse just ensure you have already generated all of your source code.

       

      For example, if you used the XDoclet Plugin for Maven to generate Hibernate mapping files, they would be placed in /target/generated-sources/xdoclet/. While, if you used the Hibernate Plugin for Maven to generate the SQL scripts for generating a database then that would be placed in /target/generated-sources/schema/.
      Settings in project.properties:

1 - 14 of 14
20 items/page
List Comments (0)