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
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?
ReplyDeleteThanks.
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