Section 2.3. Writing a Custom Goal

2.3. Writing a Custom Goal

To generate a client library for a SOAP service, you need to download the WSDL you are going to pass to wsdl2java. Define a custom goalweather:get-wsdlto download the service description from NOAA.

2.3.1. How do I do that?

To write your own goal, add some Jelly script to the weather/maven.xml file. Here's a simple custom goal that retrieves a WSDL document with Ant's get task. The custom goal is defined as follows:

<?xml version="1.0" encoding="UTF-8"?>    <project xmlns:j="jelly:core" xmlns:ant="jelly:ant"      xmlns:maven="jelly:maven" default="jar">      <goal name="weather:get-wsdl" description="Retrieves WSDL document">     <j:set var="wsdl"          value="http://weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl"/>     <ant:echo>Retrieving WSDL from ${wsdl}</ant:echo>     <ant:get src="/books/2/791/1/html/2/${wsdl}" dest="${basedir}/src/wsdl/weather.wsdl"/>   </goal>    </project>

The value of the ${wsdl} property is set with j:set, a message is printed to the console, and the document is retrieved and saved to weather/src/wsdl. This script uses the echo task from Apache Ant to print out a message, and you can run it from the command line with maven weather:get-wsdl, which produces the following output:

---

Note: In your project, the URL of the WSDL document should be defined in project.properties. This will make configuration much easier.

---

C:\dev\mavenbook\code\weather>maven weather:get-wsdl  _ _  _ _ |  \/  |_ _ _Apache_ _ _ _ _ | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~ |_|  |_\_ _,_|\_/\_ _ _|_||_|  v. 1.0.2    build:start:    weather:get-wsdl:     [echo] Retrieving WSDL from http://weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl     [get] Getting: http://weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl BUILD SUCCESSFUL Total time: 2 seconds

2.3.2. What just happened?

The j:set tag sets the wsdl property to the URL from which you are retrieving the WSDL document. When you set this variable, it is made available to the Jelly script and can be referenced with ${wsdl}. The set tag comes from the core Jelly tag library, which contains tags to allow you to set variables, perform conditional tests, and iterate over collections. This chapter is going to explore a few tags from the core Jelly tag library, such as j:if and j:forEach. For more information about Jelly's core tag library, see http://jakarta.apache.org/commons/jelly/tags.html.

The maven.xml file uses XML namespaces to identify tag libraries used in this Jelly script, and in this XML document the ant prefix is mapped to the jelly:ant namespace. The jelly:ant namespace maps directly to the Jelly Ant tag library, which allows you to call any Ant task from a Jelly script. In this task we've used Ant's echo task as it would appear in an Ant build.xml file:

<ant:echo>Print out some important message!</ant:echo>

The Ant task element needs to be associated with the jelly:ant namespace. This takes some getting used to, but rest assured, you can do anything in a custom Maven goal that you can do in an Ant build script. You can use any other Ant tasks you are familiar with; take a look at the following Maven goal from another maven.xml file:

<goal name="zipsource" prereqs="java:compile">   <ant:copy todir="${basedir}/target/src">     <ant:fileset dir="${basedir}/src/main/java">       <ant:include name="**/*.java"/>     </ant:fileset>   </ant:copy>   <ant:zip destfile="${basedir}/target/source.zip">     <ant:fileset dir="${basedir}/target/src"/>   </ant:zip> </goal>

Any Ant task you can use in a build.xml file can be used in a Jelly script. There's a comprehensive list of Ant tasks in Ant's online manual, at http://ant.apache.org/manual/index.html. Actually, the jelly:ant namespace is bound by default. Instead of using ant:copy or ant:include, you can just type copy or include if you find that more convenient. Even though you may save yourself time by omitting the ant namespace prefix, you are encouraged to use it. There is nothing particularly special about Ant, and giving it a default namespace binding is somewhat arbitrary. There is a good chance that this default binding may be removed in future versions of Maven. Always use the ant namespace prefix in Jelly.

2.3.3. What about...

...Maven being a replacement for Ant?

This isn't exactly true. Maven is not a "replacement" for Ant as much as it builds upon the success of systems such as Ant. While Ant provides projects with an XML build script, Maven is a build container. Many Maven plug-ins are built on Apache Ant tasks; in this way, Maven 1 reuses Apache Ant.