Digital Transformation

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

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.

About the Author

More from this Author

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

  1. Great information and addressed lot of unknowns.

    Are there any attachments or sample files for these articles?

    Is it possible to share the files? If yes, could you please email to my address?

    Thanks

  2. Kevin, such a great tutorial!
    Are there any chances so you coulld provide the complete file set you generated for this? Maybe even an archetype for the portlet project itself would be great!

    Thanks!

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