|Home > Documentation > User's guide > Deployment > Constructing a special-purpose 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
Liferay does not publish its code to any maven repo. Start by downloading:
and installing to your local repo:
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:
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:
in liferay-parent run
Change the plan so it looks like this:
and modify the pom setting the geronimoVersion to 2.1 and with
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
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!
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