HomeDocumentation > Configuring and administering > Configuring and administering the Apache Geronimo Server > Customizing server assemblies > Assembling a server using Maven

Deploying applications with the command line deployer or through the administration console is fine for experiments but does not fit well into an automated development workflow. The Geronimo plugin system lets you set up a workflow using maven that builds your applications, pre-deploys them as geronimo plugins, and assembles a server containing the plugins needed to run your applications. Further workflow steps could include automated testing by starting the custom server and running e.g. selenium tests against it.

In order to simplify setting up such an automated workflow we provide maven archetypes to help with setting up maven projects to build plugins and assemble servers. As an example we'll describe setting up such a workflow for the liferay 4.4.1 portal. Note that this is two steps removed from a description of how to deploy liferay on geronimo, and one step removed from a description of how to build plugins for the liferay portal. For a completed example of such a workflow see the roller plugins at https://svn.apache.org/repos/asf/geronimo/plugins/roller/trunk

Notes:

  1. Due to maven lifecycle improvements in the car-maven-plugin the assembly artifact only generates poms that work with Geronimo 2.1.1-SNAPSHOT or later. The archetypes are currently available only as snapshots from branches/2.1 and trunk.
  2. Maven tends to strip out all comments from the new pom.xml so a pom.sample.xml is included that has more comments on how to set up the pom.xml for common situations.
  3. Archetypes use some attributes (groupId, version) of parent projects when they exist. The instructions use this: for standalone use you may need to supply more command line options.
  4. Some of this would not be necessary given a project built with maven in the first place
  5. As of writing, the server starts (given enough memory) but the liferay portal doesn't show up. Hopefully we'll figure out why soon.

Process overview.

  1. Get the necessary artifacts into the local maven repo if they are not already available
  2. Construct the base maven project
  3. Use the maven war archetype to build a project to modify the artifacts as necessary using for instance the maven-war-plugin overlay to remove dependencies from WEB-INF/lib so copies in geronimo's repository can be used
  4. Use the geronimo-plugin-archetype to build projects to build plugins for the components
  5. Use the geronimo-assembly-archetype to build a project to assemble the server.

Preparation – find the artifacts

Liferay does not publish its code to any maven repo. Start by downloading:

unpacking:

and installing to your local repo:

Set up a parent maven project

I can't find an archetype to create an empty "parent" project. So...
Find a suitable location and run

Edit the pom.xml to change the packaging to pom and remove the dependency.

Also, until we publish a non-snapshot version of the archetypes, include this so the archetypes can be downloaded automatically:

Note on Geronimo Versions

Unless you are using a published archetype that goes with the version of geronimo you are using, you will have to update the <geronimoVersion> property in the generated poms to whatever the correct version is. For instance as of writing the generated poms have <geronimoVersion>2.2-SNAPSHOT</geronimoVersion> and for use with geronimo 2.1 you would update this to <geronimoVersion>2.1</geronimoVersion>

Repackage the liferay war

The JEE spec tells us to package jars used by an application in with the application in WEB-INF/lib or lib directories. This may appear to make the application more self contained but it can produce a tracking nightmare as it becomes more difficult to determine exactly what is in these directories, what version is being used, etc etc, not to mention promoting duplication of code used by several projects. Geronimo instead lets you put your jars in the maven-structured geronimo repository and specify the classloader structure for your apps to include these jars where necessary. If you want to convert an existing war project to this repository-based classloader solution you probably need to remove some of the jars from the existing war. You can do this easily with maven war overlays. For each jar you want to use from the geronimo repository, you specify an exclude in the overlay configuration and add the jar as a dependency in the maven project that builds the geronimo plugin. This example only excludes a few jars, most of which are already present in the parent classloader.

Modify the pom.xml to include the liferay war dependency

and configure the war plugin with an overlay descriptor:

Build a database plugin

in liferay-parent run

Change the plan so it looks like this:

and modify the pom setting the geronimoVersion to 2.1 and with

and

Build the liferay war plugin

run

Edit the plan so it looks like:
NOTE: this is derived from the liferay plan at and is under the liferay (MIT) license

and the pom to have geronimoVersion 2.1, liferayVersion 4.4.1 and include

and

Build an assembly

In liferay-parent run

Edit the geronimo-jetty-liferay pom to set geronimoVersion to 2.1 and include the top level modules you want in your server (console-jetty is optional)

NOTE: do not remove the boilerplate!

Run the project!

The maven project is now complete. Run it and try out the resulting server!

in liferay-parent run

To try out the resulting server you can find it in your local maven repo under .m2/repository/org/apache/geronimo/plugins/geronimo-jetty-liferay/1.0-SNAPSHOT/geronimo-jetty-liferay-1.0-SNAPSHOT-bin.tar.gz or in the build in geronimo-jetty-liferay/target.

Untar and run with

As of writing the server will start but accessing http://localhost:8080/liferay redirects to http://localhost:8080/c and gives a 404 error.