Jetspeed 2.1-dev Maven2 Build Support

The Maven2 build support is currently under development and is coresident with the existing Maven1 build scripts and sources. The general strategy is to make heavy use of Ant from within the Maven2 build or as Ant Tasks/Ant Maven2 Plugins if required. For this reason, the Maven2 build can be found in the pom.xml and build.xml files throughout the Jetspeed2 source tree. As with the Maven1 build, it is a multi-module build, primarily following the J2 component and application subprojects. There are also two Maven2 build specific top level subprojects: ant-tasks and maven-archetypes.

The development team is actively keeping both environments up to date, but the Maven2 build modifications may lag behind newly committed changes. At the moment, Maven2 does not build all LDAP related artifacts and it does not build the uberjar/classworlds executable jar files for the deploy tool. Otherwise it is generally complete, (at least AFAIK).

Maven 2.0.4 and the accompanying Ant artifact tasks are now being used for this effort, with an upgraded surefire plugin version, (2.1.3). If you wish to use the Maven2 build, please ensure that maven 2.0.4 is installed and in your path. Due to modifications in the pom.xml files, earlier versions of maven will not work correctly.

The first step in using Maven2

The first step in using the Maven2 build is to either:

copy the settings.xml.sample to ~/.m2/settings.xml or

encorporate the settings in this file into your existing Maven2 configuration.

properties customizing

Once in place, please customize the properties as one would have done for Maven1 using build.properties. The properties are preconfigured for embedded Derby, so more changes are required if another database solution is to be used. To complete this step, ensure that the proper jetspeed database active profile is uncommented for your database in the ' <activeProfiles> ' element 'jetspeed-db-drivers-path' should be selected for all non-embedded databases. This setting is needed to execute Jetspeed component tests.

Repository relocation

While the default location of the settings.xml file should not be changed, (e.g. ~/.m2/settings.xml), one can relocate the repository using the ' <localRepository> ' element in the settings.xml file. See the settings.xml.sample file for an example. Note that the repository path must be an absolute path and not contain any property expressions.

overview of current Jetspeed2 Maven2 commands

Here is a quick summary of the current Jetspeed2 Maven2 build commands, (most of these commands can be executed at the root of the J2 source tree or at lower levels to perform partial builds/deployments):

commands

explanation

mvn

performs base build and installs J2 artifacts in the Maven2 repository, (install is the default Maven2 goal for this build)

performs base build and deploys to Tomcat app server, (includes prodution database setup). Other app servers will be supported in the future, (see below for details)

mvn clean

cleans all build target directories

other commands

explanation

Please note that the Maven2 repositories used by default with this build are generally saturated and the Jetspeed2 Maven2 repository does not yet contain a full mirror of the artifacts required to build Jetspeed2. If you experience download or connection failures, simply restart the build by issuing your last command again to retry.

Additional notes:

mvn -P test and mvn -Dmaven.test.skip=false are equivalent.

mvn -P test -Dtest=MyTest will execute a single test or matching tests if Ant wildcards are used.

Due to forking bugs in the Surefire Maven2 test runner plugin, test output, (e.g. System.out.println()), is not echoed to the build shell. If you wish to see console output for component tests, temporarily comment out the <forkMode> elements in the components/pom.xml and the component's pom.xml and run single tests. Note: the forking is required to run multiple tests.

The -o offline option can be specified with the commands documented here to force Maven2 to use only the local repository. This can be invaluable in the event the main Maven2 repositories are down and the build insists upon validating a missing or troublesome POM.

Additional Profiles :

the following profiles are optional and can be supplied when building/deploying to Tomcat

mvn -P tomcat,min

specified that only the administrative portlets be deployed along with a minimal set of PSML pages.

mvn -P tomcat,full

at the moment, this is the same as the default build: deploys a full J2 set of portlets and PSML pages.

mvn -P tomcat,nodb

specifies that configuration of the production database should be skipped.

mvn -P tomcat,hot

indicates that a portlet app, component, or content should be directly written to the deployed Jetspeed2 webapp.

mvn -P tomcat,dbpsml

specifies portal build and database deployment/import to include configuration of database PSML.

Currently, only Tomcat 5 and Tomcat 5.5 application servers are supported by this build. More platforms are to be supported in the near future. To do so, additional deployment profiles and new app-servers Ant deployment build files will need to be added. See the following files for details:

pom.xml,

app-servers/tomcat-build.xml,

maven-archetypes/portal/src/archetype/archetype-resources/pom.xml, and

Use case of additional profiles:

Some of the additional profiles make sense to preconfigure in your settings.xml, (see the settings.xml.sample file for syntax)

org.apache.jetspeed.env.deploy.target, application server to deploy to. Setting this property allows one to use the generic prod profile.

org.apache.jetspeed.env.deploy.type, set to full or min. Takes the place of the full and min profiles.

org.apache.jetspeed.env.deploy.db.psml, set to true or false. Equivalent to using dbpsml if enabled.

Jetspeed 2.1-dev Maven2 Custom Portal Generation

The Maven1 j2:portal.genapp goal has been supported in the Maven2 build as an archetype. However, until a Jetspeed2 Maven2 repository is completely populated, a normal Maven2 build must be completed to make Jetspeed2 archetypes available in your local repository. One can tweak the following command as needed to create a Jetspeed2 instance using this archetype:

Note that this and other archetypes can issue many harmless warnings while expanding. Please ignore the warnings unless the expansion of the archetype template fails. When complete, the portal archetype expansion will contain the following structure within a directory named as the specified artifactId relative to the current working directory:

<artifactId>/src - these directories are an artifact of archetype expansion and should be deleted.

The archetype also contains a settings.xml.sample that is a subset of the Jetspeed2 source build parameters. If one has not previously configured the ~/.m2/settings.xml file as described above, this sample can be used to do so without J2 test configurations.

When the Maven2 enviroment is properly configured, the J2 Maven2 commands outlined above can now be used to build and deploy a customized portal. Most of the command options are supported with the exception of these profiles:

min and full are not supported because the archetype supports only the minimal deployment.

test features to populate the J2 test database have also been provisionally stripped from the archetype.

dbpsml is not yet supported in the custom portal build to import to the production database PSML.

Two additional Maven2 archetypes are also available to generate custom portal applications and components on top of the generated portal template. Before these archetypes are used, the host portal archetype should have been previously built to install all parent POMs, (it is not necessary to deploy the portal before using these archetypes). These archetypes should be created from the applications and components subdirectories to work correctly.

These dependencies can now be used to include the applications and components into the build process. Components are added as included dependencies to other applications and components in individual POMs associated with the modules that reference the component:

Shared components that are intended to be deployed as a shared JAR should be declared as a provided dependency in the applications POM or individual application and component POMs, (note the additional provided <scope> element):

Finally, the new applications and components must be added to the app-servers deployment Ant buildfiles. Applications should be added to the 'hot' application/WAR deployment hooks in the application server specific build files, (e.g. tomcat-build.xml):