Monday 18 August 2008

Ant: automated deployment to WebSphere Application Server

It can be useful to automate deployment of enterprise applications to servers during development, either to automatically set up test builds or perform build verification during the kitting process. WebSphere Application Server (WAS) comes with a number of Ant tasks that can be used for this.

Ant in WAS

WAS comes with its own version of Ant. It should be run using the ws_ant.sh script (ws_ant.bat on Windows).

[user@fedora8 bin]$ pwd
/opt/IBM/SDP70/runtimes/base_v61/profiles/AppSrv01/bin
[user@fedora8 bin]$ ./ws_ant.sh -version
Apache Ant version 1.6.5 compiled on June 2 2005

The snappily titled WebSphere Application Server Information Center (link to version 6.1) details the task API. The Ant manuals contain details of how to define the new tasks using taskdef. Since the version of Ant that ships with WAS is fixed, you may have to refer to an older version of the manual to check available tasks. Inconveniently, ws_ant.sh must be run from the server profile directory (see PK07628).

Many of the important tasks are listed below with notes as pertinent.

Classpath

The classes containing the WAS Ant tasks are in the WAS libraries. The classpath can be built dynamically at runtime.

<!-- build classpath from server libs -->
<path id="was.runtime">
<fileset dir="${was_home}/lib">
<include name="**/*.jar" />
    </fileset>
    <fileset dir="${was_home}/plugins">
        <include name="**/*.jar" />
    </fileset>
</path>
<property name="was_cp" value="${toString:was.runtime}" />

Populating EARs with deployment artefacts: wsDefaultBindings

Before an application can be deployed, it must be configured with IBM-specific deployment information. For example, the following script fragment would add a file WEB-INF/ibm-web-bnd.xmi to any WAR files contained in the EAR. This is normally done by the wizard in the web admin tools. The appropriate files are also generated by IBM development tools like Rational Application Developer. The wsDefaultBindings task can also be used to set default JNDI options, database authentication options, etcetera.

<taskdef
        name="wsDefaultBindings"
        classname="com.ibm.websphere.ant.tasks.DefaultBindings"
        classpath="${was_cp}" />
<wsDefaultBindings
        ear="${was_ear}"
        outputFile="${was_ear}"
        virtualHost="${was_virtualhost}"
        failonerror="${was_failonerror}" />

Starting and stopping the server: wsStartServer; wsStopServer

<taskdef
        name="wsStartServer"
        classname="com.ibm.websphere.ant.tasks.StartServer"
        classpath="${was_cp}" />
<wsStartServer
        username="${was_user}"
        password="${was_password}"
        server="${was_server}" failonerror="${was_failonerror}" wasHome="${was_home}" />

<taskdef
        name="wsStopServer"
        classname="com.ibm.websphere.ant.tasks.StopServer"
        classpath="${was_cp}" />
<wsStopServer
        username="${was_user}"
        password="${was_password}"
        server="${was_server}"
        failonerror="${was_failonerror}"
        wasHome="${was_home}" />

Installing and uninstalling applications: wsInstallApp; wsUninstallApp

Unlike many Ant tasks, the path required by the ear attribute of wsInstallApp is not based on the script basedir. Usually, an absolute path will be required.

<taskdef
        name="wsInstallApp"
        classname="com.ibm.websphere.ant.tasks.InstallApplication"
        classpath="${was_cp}" />
<wsInstallApp
        ear="${was_ear}"
        user="${was_user}"
        password="${was_password}"
        failonerror="${was_failonerror}"
        washome="${was_home}" />
        
<taskdef
        name="wsUninstallApp"
        classname="com.ibm.websphere.ant.tasks.UninstallApplication"
        classpath="${was_cp}" />
<wsUninstallApp
        application="${was_appname}"
        user="${was_user}"
        password="${was_password}"
        failonerror="${was_failonerror}"
        washome="${was_home}" />

Listing installed applications: wsListApp

<taskdef
        name="wsListApp"
        classname="com.ibm.websphere.ant.tasks.ListApplications"
        classpath="${was_cp}" />
<wsListApp
        wasHome="${was_home}"
        user="${was_user}"
        password="${was_password}"
        failonerror="${was_failonerror}" />

Starting and stopping applications: wsStartApp; wsStopApp

Before an application can be used, it must be started. This task is distinct to the install task.

<taskdef
        name="wsStartApp"
        classname="com.ibm.websphere.ant.tasks.StartApplication"
        classpath="${was_cp}" />
<wsStartApp
        application="${was_appname}"
        user="${was_user}"
        password="${was_password}"
        failonerror="${was_failonerror}"
        washome="${was_home}" />
        
<taskdef
        name="wsStopApp"
        classname="com.ibm.websphere.ant.tasks.StopApplication"
        classpath="${was_cp}" />
<wsStopApp
        application="${was_appname}"
        user="${was_user}"
        password="${was_password}"
        failonerror="${was_failonerror}"
        washome="${was_home}" />

Sample Code in Subversion

Repository: http://illegalargumentexception.googlecode.com/svn/trunk/code/java/
License: MIT
Project: WebSphereAntFiles

2 comments:

  1. Hey. I'm setting up auto-deployment from a jenkins slave cluster. Do you know if it's standard practise to install a copy of WAS (or the developer equiv) on every potential build agent in order to run the ws_ant targets?

    Thanks.

    ReplyDelete
  2. In scope of CI, WAS_Ant is just a tool used by Jenkins. In spite of the fact, that it comes with WAS. If you need to use it on node - than you should have it there.

    ReplyDelete

All comments are moderated