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)

mvn -P test

performs base build and includes execution of test cases, (includes test database setup)

mvn -P tomcat

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.

mvn -P prod

executes deployment to application server specified in settings.xml, (see below).

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
  • maven-archetypes/portal/src/archetype/archetype-resources/app-servers/tomcat-build.xml.

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:

mvn archetype:create -DarchetypeGroupId=org.apache.portals.jetspeed-2 -DarchetypeArtifactId=portal-archetype -DarchetypeVersion=2.1-dev -DgroupId=myportalgroup -DartifactId=myportal -Dversion=1.0

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>/applications - conventional subdirectory for portal application war modules.
  • <artifactId>/app-servers - contains portal deployment builds and resources.
  • <artifactId>/components - conventional subdirectory for portal component jar modules.
  • <artifactId>/etc/assembly - custom portal application component Spring assemblies.
  • <artifactId>/etc/conf - portal application context configuration files.
  • <artifactId>/etc/decorations - custom decorations in images, layout, and portlet subdirectories.
  • <artifactId>/etc/pages - custom portal PSML pages to augment/override minimal defaults, (e.g. /Administrative/**, /default-page.psml, /myaccount.psml, /page.security, and /system/**).
  • <artifactId>/etc/schema - Jetspeed2 database schema definitions.
  • <artifactId>/etc/sql - Jetspeed2 base database configuration scripts.
  • <artifactId>/etc/templates - custom overrides for Jetspeed2 layout portlet templates.
  • <artifactId>/etc/webapp - custom content reaources to be packaged with portal application.
  • <artifactId>/portal - portal application war build scripts and webapp resource overrides.
  • <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.

Currently, only Maven2 builds are supported. Longer range goals include support for Ant custom portal builds and prepackaged Maven2 repository downloads.

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.

A portal portlets application to be deployed by Jetspeed2:

mvn archetype:create -DarchetypeGroupId=org.apache.portals.jetspeed-2 -DarchetypeArtifactId=application-archetype -DarchetypeVersion=2.1-dev -DgroupId=myportalgroup -DartifactId=myportal-application -Dversion=1.0

A simple component to be used by other component and application modules:

mvn archetype:create -DarchetypeGroupId=org.apache.portals.jetspeed-2 -DarchetypeArtifactId=component-archetype -DarchetypeVersion=2.1-dev -DgroupId=myportalgroup -DartifactId=myportal-component -Dversion=1.0

A shared component to be deployed as a shared JAR in the application server:

mvn archetype:create -DarchetypeGroupId=org.apache.portals.jetspeed-2 -DarchetypeArtifactId=shared-component-archetype -DarchetypeVersion=2.1-dev -DgroupId=myportalgroup -DartifactId=myportal-shared-component -Dversion=1.0

A component to be deployed within the portal, (Jetspeed2), web application:

mvn archetype:create -DarchetypeGroupId=org.apache.portals.jetspeed-2 -DarchetypeArtifactId=portal-component-archetype -DarchetypeVersion=2.1-dev -DgroupId=myportalgroup -DartifactId=myportal-portal-component -Dversion=1.0

Note that the groupId and version settings should match the values used when generating the host portal template.

There are a few manual steps that must be followed to use these created applications and components.

  1. The new application/component must be added as <module> elements in the parent POM. An application would be added like this by subdirectory name, (artifactId):
    <modules>
        ...
        <module>myportal-application</module>
        ...
    </modules>
    
    The same syntax is used for components.
  2. A dependency declaration should be added in the root POM. Components packaged as jars should be added like this:
    <dependencyManagement>
        <dependencies>
            ...
            <dependency>
                <groupId>${pom.groupId}</groupId>
                <artifactId>myportal-component</artifactId>
                <version>${pom.version}</version>
            </dependency>
            ...
        </dependencies>
    </dependencyManagement>
    
    Applications are declared similarly, except for the addition of a required <type> element:
    <dependencyManagement>
        <dependencies>
            ...
            <dependency>
                <groupId>${pom.groupId}</groupId>
                <artifactId>myportal-application</artifactId>
                <type>war</type>
                <version>${pom.version}</version>
            </dependency>
            ...
        </dependencies>
    </dependencyManagement>
    

  3. 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:
    <dependencies>
        ...
        <dependency>
            <groupId>${pom.groupId}</groupId>
            <artifactId>myportal-component</artifactId>
        </dependency>
        ...
    </dependencies>
    
    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):
    <dependencies>
        ...
        <dependency>
            <groupId>${pom.groupId}</groupId>
            <artifactId>myportal-shared-component</artifactId>
            <scope>provided</scope>
        </dependency>
        ...
    </dependencies>
    
    Shared and portal components must also be made available for deployment and should be integrated in the app-servers module POM as a normal dependency:
    <dependencies>
        ...
        <dependency>
            <groupId>${pom.groupId}</groupId>
            <artifactId>myportal-shared-component</artifactId>
        </dependency>
        ...
    </dependencies>
    
    Applications are normally referenced only for deployment. To ensure they are available during deployment builds, they must be integrated in the app-servers module POM like this:
    <dependencies>
        ...
        <dependency>
            <groupId>${pom.groupId}</groupId>
            <artifactId>myportal-application</artifactId>
            <type>war</type>
        </dependency>
        ...
    </dependencies>
    

  4. 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):
    <target name="hot-deploy-apps">
        ...
        <antcall target="hot-deploy-war">
            <param name="org.apache.jetspeed.deploy.groupid" value="${portal.groupid}"/>
            <param name="org.apache.jetspeed.deploy.artifactid" value="myportal-application"/>
            <param name="org.apache.jetspeed.deploy.version" value="${portal.version}"/>
        </antcall>
        ...
    </target>
    
    Shared components that are to be installed in the application server should be added to the shared deployment hook in the same buildfile:
    <target name="hot-deploy-shared-components">
        ...
        <antcall target="hot-deploy-shared-jar">
            <param name="org.apache.jetspeed.deploy.groupid" value="${portal.groupid}"/>
            <param name="org.apache.jetspeed.deploy.artifactid" value="myportal-shared-component"/>
            <param name="org.apache.jetspeed.deploy.version" value="${portal.version}"/>
        </antcall>
        ...
    </target>
    
    And finally, portal components that are to be inserted into the portal application itself should be added to the 'hot' component/JAR hooks like this:
    <target name="hot-deploy-components">
        ...
        <antcall target="hot-deploy-jar">
            <param name="org.apache.jetspeed.deploy.groupid" value="${portal.groupid}"/>
            <param name="org.apache.jetspeed.deploy.artifactid" value="myportal-portal-component"/>
            <param name="org.apache.jetspeed.deploy.version" value="${portal.version}"/>
        </antcall>
        ...
    </target>
    

Please refer to the Maven2 site documentation for more detail or background information: http://maven.apache.org/guides/index.html.

  • No labels