Using Maven 2 to Build WebLogic Portal Applications

by Gerald Nunn
03/07/2007

The purpose of this tutorial is to show how to create a build system for BEA WebLogic Portal using the Apache Maven 2 project. Maven is an open-source build system that is used on many Apache projects. It provides a number of interesting features that go beyond Ant, the most compelling being the dependency management features. The debate about Maven versus Ant is often a heated one, and this tutorial will not be addressing this issue; instead, it will focus solely on the use of Maven 2 with WebLogic Portal.

This tutorial assumes that you are familiar with Maven 2 and the basic functionality it provides. If you are new to Maven, a recommended resource is the free e-book
Better Builds with Maven 2.

Setting Up Maven

The first step to take is to install a copy of Maven 2, which can be done by downloading it from the Maven Web site at
http://maven.apache.org. Maven can be installed in any location on the file system, however you should not install it in a project-specific directory since you may want to utilize it across different projects.

Once Maven is installed, the next step is to create a small command file to initialize the Maven environment. An example file is shown below; this file is for Windows although it would be simple to create an equivalent for Linux or Solaris.

set BEA_HOME=C:\bea92
set M2_HOME=C:\java\maven-2.0.4
set JAVA_HOME=%BEA_HOME%\jdk150_04
set path=%JAVA_HOME%\bin;%path%;%M2_HOME%\bin
mvn --version

This script simply sets certain environment variables that will be used by the build environment. Obviously, you should change the
BEA_HOME,
JAVA_HOME, and
M2_HOME variables to reflect your specific environment. The end of the script runs the Maven version command to ensure the script is correct. This command simply displays the version of Maven that is being used.

Creating the Maven Repository

A key feature of Maven is the management of dependencies. A build that depends on a resource declares a dependency in the Maven build file, specifying the dependency's group, name, and version. When the build is invoked, Maven resolves these resource dependencies by fetching the necessary resources from a repository. To facilitate this, Maven maintains a large repository at
http://repo1.maven.org/maven2 that includes most of the popular open-source frameworks like Spring.

Unfortunately, this repository cannot host commercial resources such as WebLogic libraries because this would violate various copyrights and licensing agreements. As a result, the next step is to install the WebLogic libraries into a local repository. As a first thought, developers may be tempted to simply refer to the resources on the file system using the system scope, however as we will see later this will not work in the case of shared libraries. Additionally, it goes against the philosophy of Maven and therefore should be avoided.

Installing Stand-alone JARs

Installing the stand-alone JARs from your BEA home directory is quite simple. Below is a sample line from a script that shows how to do this using the Maven install plug-in and the install-file goal. For the sake of conciseness, only a single line is shown; the full script is included in the sample code. This script assumes that you are using WebLogic Portal 9.2. If you have installed MP1 or a later version, it is recommended you update the version numbers in the script accordingly.

Maven resources are stored in a repository with a group identifier, an artifact identifier, and a version number. The group identifier is used to group similar artifacts together. In the case above, we use
weblogic-server to group WebLogic Server-specific artifacts. Later on in the tutorial we will also introduce the
weblogic-portal and
weblogic-common groups as well. The artifact identifier uniquely identifies the specific artifact. For the sake of clarity, we recommend that the name of the JAR be used as the artifact identifier.

Note that the group and artifact identifiers are exactly what we used to develop this tutorial. Developers are free to use whatever hierarchy and naming convention they prefer, but any changes need to be reflected in all of the build artifacts that accompany this tutorial.

Once the WebLogic resources are in the library, referencing the resource in Maven's project object model (POM) is straightforward. With respect to the previous example of installing the
weblogic.jar in the repository, we would create a dependency on this in
pom.xml, as shown below.

Note that the group and artifact identifier along with the version are identical to what we used to install
weblogic.jar in the Maven repository. The provided scope simply indicates that the resource is provided at runtime and should be used only for compilation purposes.

Working with Shared Libraries

Unfortunately, we now face a more difficult challenge, namely installing WebLogic's shared libraries into the repository. A shared library is a Web or enterprise archive that is merged at runtime with an application. Applications declare dependencies on shared libraries in either the
weblogic-application.xml in an EAR or
weblogic.xml in a WAR. These shared libraries can include a variety of resources such as JAR files.

The problem with a shared library is that the Java compiler,
javac, is not able to extract the JAR files from the shared library to perform a compilation. In WebLogic Workshop there is a plug-in that expands all the shared libraries into one of the workspace's plug-in directories so that the individual JAR files will be available to the compiler.

With respect to Maven, to access shared libraries we need to install each artifact in each shared library into the Maven repository. To accomplish this goal, a small maven plug-in called
maven-weblogic-library-plugin was written to accompany this tutorial. This plug-in works similarly to the Maven install plug-in except it installs one or more shared libraries into the repository. Here is an example of how to execute it:

This plug-in can install either a single share library using the
-Dlibrary switch or all libraries in a specified directory, as shown above. The
groupId that is specified above is the root group into which to install the shared library. The plug-in will automatically create a secondary group for the library artifacts whose name is the same as the library. Under this secondary group, each artifact from the shared library will be installed along with a copy of the library itself. Finally, a parent Project Object Model (POM) artifact will be created that can be used to create dependencies on all of the artifacts in the library. This saves on the effort of creating a dependency on each individual artifact when setting up the build.

Versioning

The
maven-weblogic-library-plugin plug-in allows the developer to specify the default version of the shared library. This is used when the shared library does not include a version number in its name. If a shared library such as
beehive-controls-1.0.ear is installed, the version number will be taken from the name, in this case 1.0, instead of coming from the default version number.

Building the
maven-weblogic-library-plugin Plug-in

To build the plug-in, go to the
/maven/maven-weblogic-library-plugin folder in the sample code and execute
mvn:package followed by
mvn:install. Remember to first initialize the Maven environment using the included
maven.bat file discussed earlier.

Installing the Shared Libraries

Now that we have the plug-in, the next step is to install all of the shared libraries into the repository. Included in the sample code is a script,
install-weblogic-libraries.bat, that shows how to do this.

Once the shared libraries are installed we can include dependencies on them by using the parent POM that our plug-in created, as discussed earlier. For example, to declare a dependency on the
p13n-app-lib.ear shared library, we would use the following dependency declaration in our
pom.xml: