WebSphere Portal and Maven (Part 2)

This post assumes that you have installed an automated build stack (which consists of maven, a maven compatible repository server, and a continuous integration (CI) server). This post also assumes that you have installed and configured the m2eclipse plugin for your RAD/Eclipse IDE. The details of these installations are beyond the scope of this series of posts.

A maven repository is software (like archiva or nexus) that stores your dependencies in a single remote server. Corporate development shops often choose to maintain an internal repository server which mirrors the maven central repository. The internal repository offers greater control, security, and faster internal downloads. IBM does not publish the portal dependencies to the maven central repository. (You will find that the majority of open sources projects will publish to maven central).

Since IBM does not publish the portlet dependencies you need an internal repository for compiling portlets (unless you use the system dependency scope and a private repository, but I don’t think this approach is as maintainable in a team development setting.)

So what are your dependencies?

I have taken two approaches for figuring this out:

1. Go into RAD and find the Project Build Path and examine the WebSphere Portal v7.0 library definition and copy all the jar names and locations. Upload all these files to your internal server. List all these files as provided scope dependencies in your project. I’ll admit I have done this before figuring out the next method.
2. Locate the ${PortalServer}/doc/compile/portletapi_20.jar file and list this as a provided scope dependency.

What is the difference between these methods?

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

If I developed any bizarre classpath issues (like NoSuchMethodError) I would revert to the first method to ensure I was replicating the RAD wizard exactly.

You use the provided scope of maven because you want to compile your code using the jar but the actual implementation jars are provided by the portal server when you deploy the code to a running portal server. The following command deploys your dependency to a remote maven repository:

mvn deploy:deploy-file -DgroupId=com.ibm.portal -DartifactId=portletapi20 -Dversion=7.0 -Dpackaging=jar -Dfile=portletapi_20.jar -DrepositoryId=${repnamehere} -Durl=${repurlhere}

You should note that all these parameter values were items thought up by you. I find that using artifactId=${name}.jar without the jar extension and using a version number to correspond to your WebSphere Portal Server (WPS) version help maintain the logical link between these jars and their source. Finally ${repnamehere} and ${repurlhere} are values that make sense at your organization.

I always create a parent maven project of type pom that each portlet project inherits from (the reasons for this will become clearer in future posts). This parent project links the dependency as:

<dependency>

<groupId>com.ibm.portal</groupId>

<artifactId>portletapi_20</artifactId>

<version>7.0</version>

<scope>provided</scope>

</dependency>

At this point your portlet project can compile and will be packaged as a WAR file suitable for deployment on your portal server.

Next up: WebSphere Portal and Maven (Part 3)