Build Sakai with Maven 2

18 07 2007

Maven 2 is upon us… so here is a quick refresh.

1. Install maven 2.0.6 or later by unziping/untaring the binary download from

2. Get the mvn command onto the path (in the bin directory of the binary package)

3. cd to sakai source

4. type

export MAVEN_OPTS='-Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=128m'

mvn clean  #to clean the build

mvn install #to build and install in the local repository

mvn -Dmaven.tomcat.home=/Users/ieb/mytomcat sakai:deploy
#to deploy to mytomcat

Thats it…. no configuration required, its all in the build itself.

Some more usage

mvn -Dmaven.test.skip=true \
                   -Dmaven.tomcat.home=/Users/ieb/mytomcat \
                   clean install sakai:deploy

To clean, install and deploy skipping tests.

If you have already done a build and know that everything has been fetched from remote repositories, you can add the -o switch to go offline.

Coversion of Sakai to Maven 2 build

13 07 2007

A long time ago, we started the conversion work on Sakai to make it use a Maven 2 build, partly because it promised to give us better control over dependencies but also because many of the projects we use in Sakai were also moving to a maven 2 build.

Sakai has many classloaders, which pushes the boundaries of what maven 2 can do to define and categorize dependencies and how they are packed. In fact maven 2.0.4 had some bugs that were not fixed until 2.0.6 that made it rather difficult to express these classloader boundaries. We are now at maven 2.0.7 and I, with the help of Alistair Young from University of Highlands and Islands (UHI)… the Glaswegian who made everyone laugh about Shibboleth at Amsterdam… have migrated the build to a hierarchical build structure based on project boundaries. We have check the deployment profile of all the wars to make certain they are cleaner than the maven 1 build.

So, if you have a maven 1 project in contrib or provisional that is not part of the main build, I am sorry I we haven’t been able to convert your project, there are just too many of them… here is how the build structure works.

In /master/pom.xml we define with dependencyManagement the contents of the shared and common classloaders, so that if your project depends on a shared of common jar, it will be automatically excluded from a pack operation. If your project is provisional or contrib, then you will have to manually exclude your shared jars as they are not part of the “official” shared/common profile.

The base project of sakai (called groupId org.sakaiproject artifactId base ) has the master project as a parent. Your project should have the base pom as its parent. Then all child poms in your project should have the base pom of the project as a parent.

Maven2 repository distribution

3 07 2007

The maven wagon plugin support a greater number of plugins to perform distribution than the standard maven, which is good because doing a maven 2 deploy of a new artifact is a pain. However, webdav support is not quite there. It works just fine (in beta2) to do a deploy to an exising folder in the repo, but when there is no folder structure there, it fails.

I have found that if you webdav mount the destincation locally and then use the file:/// protocol to perform the distribution management, then it all works just fine. It would be nice if the webdav protocol handler for wagon supported mkdir on missing directories…. but the workarround works just fine on OSX.