Jetspeed plugin supports two models:
Here are some advantages of using Jetspeed plugin:
| Goal | Description |
|---|---|
| jetspeed:hotdeploy | Deploys changed resources directly to live webapp |
| jetspeed:deploy | Builds a .war file and deploys it to servlet container |
| jetspeed:genapp | Generates a sample application using information gathered from the command line |
| Goal | Description |
|---|---|
| jetspeed:war | Generates custom portal .war file based on Jetspeed binary distribution |
| jetspeed:war-version-tag | Updates release version tag shown in the bottom navigation |
| jetspeed:war-config | Override jetspeed property files and add local registries |
| jetspeed:generate-project | Generates starter custom portal project based on specific version of Jetspeed binary distribution. This will include a project.xml file with dependencies taken from the binary distribution. While this goal would be very useful IT IS NOT IMPLEMENTED ;-) |
This is the main goal use for building your custom portal .war file. Before invoking this goal, you must create a maven project containing your customizations to Jetspeed. These customizations may be as simple as changing few Jetspeed properties or as sophisticated as customizing the entire look and feel of the portal and/or creating custom portlets and services.
You may refer to Jetspeed Tutorial for an example of project utilizing Jetspeed plugin.
Currently, this goal will replace token (release) in templates/vm/navigations/html/bottom.vm with current version from project.xml. Invoked by jetspeed:war.
This goal merges your custom properties with base Jetspeed properties contained in the binary distribution. You specify which property files to merge using maven.merge.properties property. You may have separate property merge file for each of your target environments (target environment is specified using maven.env.name property). For example:
maven.merge.properties = JetspeedResources,TurbineResources,JetspeedSecurity,Torque,log4j
The plugin will look for the above in your project. Each of your merge files should be named using the following convention:
| Goal | Description |
|---|---|
| jetspeed:overlay | Overlays jetspeed .war file with your customizations |
| jetspeed:merge-properties | Prerequisite to jetspeed:overlay, merges your property overrides with Jetspeed's properties |
This goal should be used when you want to take your code, overlay over a plain vanilla jetspeed war file, and then run cactus tests against the resulting codebase. That way your cactus tests do not have to deal with what the current state of the production jetspeed version.
The goal takes a vanilla Jetspeed war specified in the project.properties as maven.jetspeed.vanilla.war=C:/portal/src/jetspeed-upstate/portal2.war and expands it into a working directory. Then the project is turned into a WAR file, and expanded over the vanilla \ installation in the working directory. Lastly, the properties files are merged in. The resulting overlayed codebase is then re WAR'ed, and the plugin places the new war in the orignal war location, but with all the overlayed code and merged properties.
This is useful when running cactus tests, as you can just run:
maven war:webapp jetspeed:overlay cactus:test
This goal is called by jetspeed:overlay to merge in specific properties files into the base vanilla jetspeed installation. Currently this is pretty rigidly definied which files are merged.
The plugin expects the files to be in ${maven.jetspeed.merge.dir}/MergeJetspeedResources.properties, and typically the maven.jetspeed.merge.dir is in the ./src/conf directory of your webapp. The files that are currently merged are:
These are merged into the corresponding default versions (without the word Merge ;-) ).