WebSphere Portal and Maven (Part 6)

You use a parent pom.xml file that each portlet project inherits from to encapsulate your dependencies and maven plugin bindings. This keeps all this code out of sight from your portlet project.

This first code posting shows the plugin definition under a pluginManagement section. This section is used to create any dependencies used by the plugin itself:

...
<pluginManagement>
	<plugins>
		<plugin>
			<groupId>com.mycompany</groupId>
			<artifactId>portlet-deploy</artifactId>
			<version>1.0.0-SNAPSHOT</version>
			<dependencies>
				<!-- Needed for ANT scp task -->
				<dependency>
					<groupId>org.apache.ant</groupId>
					<artifactId>ant-jsch</artifactId>
					<version>1.7.1</version>
				</dependency>
				<!-- Needed for propertyregexp task -->
				<dependency>
					<groupId>ant-contrib</groupId>
					<artifactId>ant-contrib</artifactId>
					<version>1.0b3</version>
				</dependency>
				<dependency>
					<groupId>ant</groupId>
					<artifactId>ant-optional</artifactId>
					<version>1.5.3-1</version>
				</dependency>
				<!-- END: Needed for propertyregexp task -->
				<!-- For XSLT transformations -->
				<dependency>
					<groupId>ant</groupId>

				<artifactId>ant-trax</artifactId>
					<version>1.6.5</version>
				</dependency>
				<!-- For xmlaccess scripts -->
				<dependency>
					<groupId>com.ibm.portal</groupId>
					<artifactId>wp.xml.client</artifactId>
					<version>7.0</version>
				</dependency>
				<dependency>
					<groupId>com.ibm.portal</groupId>
					<artifactId>wp.base</artifactId>
					<version>7.0</version>
				</dependency>
				<!-- END: For xmlaccess scripts -->
				<!--  For pznload scripts -->
				<dependency>
				  <groupId>com.ibm.portal</groupId>
				  <artifactId>pznpublish</artifactId>
				  <version>7.0</version>
				</dependency>
				<dependency>
				  <groupId>com.ibm.portal</groupId>
				  <artifactId>wp.content.repository.client</artifactId>
				  <version>7.0</version>
				</dependency>
				<dependency>
				  <groupId>com.ibm.portal</groupId>
				  <artifactId>pznruntime</artifactId>
				  <version>7.0</version>
				</dependency>
				<dependency>
				  <groupId>com.ibm.portal</groupId>
				  <artifactId>pzncommon</artifactId>
				  <version>7.0</version>
				</dependency>
				<dependency>
				  <groupId>com.ibm.portal</groupId>
				  <artifactId>pznnls</artifactId>
				  <version>7.0</version>
				</dependency>
				<dependency>
				  <groupId>com.ibm.portal</groupId>
				  <artifactId>workmanager</artifactId>
				  <version>7.0</version>
				</dependency>
				<!--  END: For pznload scripts -->
			</dependencies>
		</plugin>
	</plugins>
</pluginManagement>
...

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

The code above assumes that you loaded the necessary IBM portal jars using an artifactId name of the jar filename without the .jar extension. The post includes some extra jars needed for personalization functionality (PZN) which will be covered in a future post. Remember that the ellipses in the code (at beginning and end) represent the rest of your XML and should not be copied themselves.

The next section shows the code that binds your plugin to the maven lifecycle. The pre-integration-test phase is used so that integration test failures can prevent the installation of a flawed portlet in your local repository (on the developer machine) or worse in your snapshot repository (when the deploy goal is executed from your continuous integration server):

...

<plugins>
	<plugin>
		<groupId>com.mycompany</groupId>
		<artifactId>portlet-deploy</artifactId>
		<executions>
			<execution>
				<phase>pre-integration-test</phase>
				<goals>
					<goal>deploy</goal>
				</goals>
			</execution>
		</executions>
	</plugin>
</plugins>

...

Note that the deployment will not work unless you use an IBM JDK (and not the Sun JDK included by default on most windows machines) to compile and deploy with. The configuration of this is beyond the scope of this post.

This concludes the basic infrastructure you need for deploying portlets using maven. However, there are other portal artifacts that can benefit from maven. The basic techniques of generating scripts from existing descriptor files generally remains the same for these other items.

If you made it this far you will probably be interested in Release Management for WebSphere Portal.