Maven and WebSphere Web Applications (Part 2)

The parent project of the multiple module web application uses the uses the <packaging>pom</packaging> tag and several <module> tags to indicate that it is controlling the build order of several artifacts. The control is provided through the reactor plugin.

The file structure that I use is:

    /ear

    /ear/pom.xml

    /web

    /web/pom.xml

.classpath

.project

pom.xml

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

The ear directory is empty  (except for pom.xml). The application.xml required for an EAR is generated by the was6 maven plugin. The directory structure of the web directory is not shown here but specified as the maven standard directory layout.

There are several fields in the various hidden control structures that must be internally consistent for the build and deploy to work. This is why I prefer to use a maven archetype (created yourself for your project team) project to generate web application projects from scratch. My experience in the field indicates that developers who copy and paste from existing projects often make mistakes which are very hard to diagnose.

These are the items that you need to address:

• Provide unique namespace (groupId + artifactId) for ear and war modules that is predictable. I solve this by using parent groupId appended with .war or .ear for the child projects.
• Ensure the parent/child relationship of the three pom.xml files through dependencies and parent references including the correct generated ids.
• Ensure ibm-web-ext.xml and ibm-web-bnd.xml are included in the web module.
• Ensure the .project and .classpath files include the correct RAD facets and library definitions for a maven project.
• Ensure the parent pom.xml has a parent reference to a project that defines the required WAS dependencies (for proper compilation).

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-ear-plugin</artifactId>
	<version>2.3.2</version>
	<configuration>
		<modules>
			<webModule>
				<groupId>com.yourcompany.${artifactId}.web</groupId>
				<artifactId>${artifactId}Web</artifactId>
				<contextRoot>${artifactId}</contextRoot>
			</webModule>
		</modules>
	</configuration>
</plugin>

<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>was6-maven-plugin</artifactId>
	<executions>
		<execution>
			<phase>pre-integration-test</phase>
			<goals>
				<goal>installApp</goal>
			</goals>
		</execution>
	</executions>
	<configuration>
		<earFile>target/${artifactId}Ear-${version}.ear</earFile>
		<applicationName>${artifactId}</applicationName>
	</configuration>
</plugin>

<was6.wasHome></was6.wasHome>
<was6.targetServer></was6.targetServer>
<was6.server></was6.server>
<was6.conntype></was6.conntype>
<was6.port></was6.port>
<was6.username></was6.username>
<was6.password></was6.password>
<was6.host></was6.host>

You specify text values for each of the properties above that make sense on your machine. Note that was6.server and was6.targetServer will actually be the same value. You include them both because different goals of the was6 plugin used different parameter names to express the same logical value. Sometimes open source will contain idiosyncratic annoyances (but hey, you can’t beat the price!)

In the next post I will examine how the web module is processed when you are creating a portal theme or skin.