Digital Transformation

WebSphere Portal and Maven (Part 4)

So far you have a compiled portlet and an XSLT capable of producing an xmlaccess request input file based on your specific portlet.xml file.

Next you create an ANT script that is capable of submitting your request to the portal server. The script presented below diverges to distinguish between local portlet deployments (when you are deploying to a portal server on the same machine on which you are building) and remote portlet deployments (when you are deploying to a remote portal server). The divergence is because local portlet deployments do not require any copying of the generated WAR file. For remote deployments I use the ANT scp task to copy the WAR file to the remote machine.

I prefer the scp task because you can place the file into the ${wp_profile}/installableApps directory (which follows standard IBM practice). This method requires that you have a shell account on the remote machine with correct write privileges. I’ll admit that I have used the nexus/archiva snapshot repository URL as an input to the xmlaccess request when I didn’t have a shell account. This hack avoids the copying procedure, but I would avoid this method when possible because the logic to predict the URL is not as robust. You can plug any type of remote copying or URL based sharing method into this portion of the script.

The name of your web module in the wps admin console will default to ${artifactId}-${version}.war because that is derived from the filename of the deployed WAR file. Adjusting this would require some deeper level maven hacks that I like to avoid. However, the name of your web module in the AppServer admin console is under your control. I like to use ${MyCompany}_ as a prefix so that all your projects can be quickly filtered to distinguish them from the existing IBM modules.

Here is the ANT script:

<project default="install.local">
	<target name="install.local" depends="private.local.init, private.deploy" />
	<target name="install.remote" depends="private.remote.init, private.deploy" />

	<target name="private.local.init">
		<property name="file.url" value="file:///${basedir}/${project.artifactId}-${project.version}.war" />

	<target name="private.deploy">
		<!-- Step 1: Generate xmlaccess input from portlet.xml -->
		<echo message="Step 1: Generate xmlaccess request: target/deployme.xml" />
		<xslt in="../WebContent/WEB-INF/portlet.xml" out="deployme.xml" force="true" style="xmlaccess-input.xsl">
			<param name="WAR_URL" expression="${file.url}" />
			<param name="DISPLAY_NAME" expression="MyCompany_${project.artifactId}" />

		<!-- Step 2: Run the install/update xmlaccess script -->
		<!-- If the java process is forked then the CLASSPATH must be set  -->
		<echo message="Step 2: Deploying portlet using xmlaccess input: target/deployme.xml" />
		<java classname="" logError="true" resultproperty="xmlaccessReturnCode">
			<arg line="-in target/deployme.xml" />
			<arg line="-user ${wpsuser}" />
			<arg line="-password ${wpspassword}" />
			<arg line="-url http://${wpshost}:${wpsport}/${wpscontext}/config" />
			<arg line="-out target/output.xml" />

		<!-- Step 3: Determine result of deployment attempt -->
		<echo message="Step 3: Determine script result..." />
		<taskdef resource="net/sf/antcontrib/antlib.xml" />
				<equals arg1="${xmlaccessReturnCode}" arg2="0" />
				<length property="fileLength" file="output.xml" />
				<loadfile property="output.result" srcFile="output.xml" />
				<condition property="output.result" value="output.xml is empty">
					<equals arg1="${fileLength}" arg2="0" />
				<echo message="----- output.xml starts -----" />
				<echo message="----- output.xml ends ----/apps/IBM/Profiles-" />
				<fail message="Execution of deployme.xml Failed">
							<equals arg1="${xmlaccessReturnCode}" arg2="0" />
				<echo message="Execution of deployme.xml OK" />

	<!--Use SCP to copy the WAR file to the remote machine -->
	<target name="private.remote.init">
		<scp file="${project.artifactId}-${project.version}.war" todir="${scpuser}@${wpshost}:${remotedir}" password="${scppassword}" trust="true" />
		<property name="file.url" value="file:///${remotedir}/${project.artifactId}-${project.version}.war" />

The next post in the series will explain how the XSLT and and the ANT code is combined in a maven plugin to perform your portlet deployment.

Next up: WebSphere Portal and Maven (Part 5)


About the Author

More from this Author

Thoughts on “WebSphere Portal and Maven (Part 4)”

  1. This is a nice series of articles. The past few clients I’ve been to have either already had an automated build and deploy process in place or had no interest in setting it up.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to the Weekly Blog Digest:

Sign Up