SipX ConfigServer Maven

From SIPfoundry sipx, The Open Source SIP PBX for Linux - Calivia

[edit] Goals

By switching the sipXconfig build from Ant to Maven2 we hope to achieve the following:

• simplify the sipXconfig build process - we have a combination of property files and ant scripts that support quite a sophisticated build process: however most of the functionality is non-standard and not easily accessible
• dependency management - we need to keep up with newer version of libraries - we have to maintain a stable snapshot of about 90 jars in the sipXconfig repository: it is difficult and time-consuming now and it's only going to get harder when sipXconfig grows
• creating new modules shoud be easy: web module should be split into soap and ui modules: we did not do it because at the moment creating new modules involves some copying and pasting, it has to be cheaper if we want to maintain relatively good isolation between different functional areas
• ant classpath problems - ant-based builds are not easily portable because there is no standard way of modifying ant classpath on different distros: we rely on jpackage and its ant-xxxx modules but on couple of occasions we had classpath problems

The major difference between ant and maven2 is that while ant is prescriptive (you tell it what to do to build your project) maven is descriptive (you tell it what your project is and it knows how to build it). Our hope is that it will result in shorter, simpler build infrastructure.

There will be only a single dependency (maven to install) and the build process will remain accessible from make so that C/C++ sipX developers can build sipXconfig without learning Java-centric technologies.

[edit] Installation

• install JDK 1.5
• install Maven2
  • download maven2 (2.0.2 or later) from: http://maven.apache.org/download.html
  • unpack it to your local software directory, for example /usr/local/maven-2.0.2/
  • make it accessible from command line: one of the ways to do it is to create symbolic links

 ln -s /usr/local/maven-2.0.2 /usr/local/maven
 ln -s /usr/maven/bin/mvn /usr/local/bin

• configure repository mirrors - (strictly speaking this is an optional step, you have to do that if download of dependencies from central maven2 repository is slow or unreliable)

 <?xml version="1.0"?>
 <settings>
  <mirrors>
    <mirror>
      <id>ibiblio.net</id>
      <url>http://www.ibiblio.net/pub/packages/maven2</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
    <mirror>
      <id>lsu.edu</id>
      <url>http://ibiblio.lsu.edu/main/pub/packages/maven2</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
  </mirrors>
 </settings>
 

the last mirror is active you can switch them if you have problems downloading

• initialize maven respository - maven will retrieve most of the dependencies, however for licensing reasons the repositories do not include several Sun jars it's best to install the directly using .jars in sipXconfig/lib repository

 cd $SIPX_SRC/sipXconfig/lib
 mvn install:install-file -Dfile=jta.jar -DgroupId=javax.transaction -DartifactId=jta -Dversion=1.0.1B -Dpackaging=jar
 mvn install:install-file -Dfile=javamail-1.3.2.jar -DgroupId=javax.mail -DartifactId=mail -Dversion=1.3.2 -Dpackaging=jar
 mvn install:install-file -Dfile=activation-1.0.2.jar -DgroupId=javax.activation -DartifactId=activation -Dversion=1.0.2 -Dpackaging=jar
 mvn install:install-file -Dfile=j2ee_connector-1_0-fr-class.zip -DgroupId=javax.resource -DartifactId=connector -Dversion=1.0 -Dpackaging=jar

[edit] Build commands

You need to set up SIPX_SRC environment variable to point to your workplace directory (parent of sipXconfig directory).

 export SIPXCONFIG_SRC=/home/developer/work/sipx/main/sipXconfig

Then you can call maven targets:

 mvn clean # clean your project

 mvn compile # compile and check sources (using checkstyle)

 mvn test # compile + check + test

 mvn package # compile + check + test + create .jar and .war files

 mvn -Dmaven.test.skip=true clena package # clean compile and create .jar and war.

If you run maven from sipXconfig directory it will recursively build all modules.

By default build results are located in sipXconfig/build.maven directory. You can change it by setting top.build.dir property. For example:

 mvn -Dtop.build.dir=/tmp compile

To see the list of goals (mojos) for a plugin try this:

 mvn help:describe -Dfull=true -Dplugin=checkstyle

[edit] Issues

List of all the things that do not work as desired at the moment (either due to maven2 limitations, bugs or just because we do not know how to configure it yet).

compile

• it would be better not to use environment variable to specify build directory - at the moment it is required because we want one build directory per sipXconfig project (and not separate directories for neoconf and web modules which is the way maven wants it)

resources

• resource filtering (expanding environment variables) works only for ANT like resources - we have several files with @tokens.like.this.one@ - we can either continue to use ant to expand them
• I cannot find the way of changing name of the filtered resource from file.extension.in to file.extension in the destination directory

tests

• integration tests (DB, web and performance tests) are not enabled yet
• many tests are writing to standard output - need to stop this
• test failed report is not very useful = one has to browse surefire-reports directory for failed tests
• problems with xercesImpl: our tests blindly switch XML parser to xerces, which upsets most maven plugins: temporary fix is to fork all the tests once but we might reconsider our approach

jetty run

• sipxconfig.properties is created

package/installation

• it's hard if not impossible to create a war file that would *not* include dependent jars in /lib directory - this is not how we were doing this so far our war file was pretty small and we launched jetty with classpath containing all the .jar files: I am not sure which method is better but I am reluctant to change it just because maven plugin cannot be used to package .war file without dependencies
• assembly plugin is not documented very well - the intention would be to use it during installation phase, not only to install dependencies but also to replace other tasks performed