SCALING YOUR TEAM in Font

Generator DataMatrix in Font SCALING YOUR TEAM

Maven is well integrated into the Java ecosystem. There are test goals for JUnit, TestNG, and so on. There are Maven plug-ins to most of the IDEs. Every Apache JVM-related open source project publishes its JARs to the central Maven repository, as do most other open source projects. There s excellent Maven support for Scala courtesy of David Bernard and Josh Suereth. You can learn more about it at http://scala-tools.org/mvnsites/maven-scala-plugin/. The Lift Web Framework uses Maven, and I use Maven in all my projects and love it. Others disagree because Maven is opaque in how it resolves dependencies; Maven downloads the entire Internet (all your dependencies and those dependencies dependencies, and so on) the first time you build; Maven is challenging when debugging failures; and Maven s XML verbosity is overly verbose. The last complaint is one I heartily agree with. Here s a sample Maven file:

< xml version="1.0" encoding="UTF-8" > <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <modelVersion>4.0.0</modelVersion> <groupId>info.spitballs</groupId> <artifactId>spitballs</artifactId> <version>0.1.0-SNAPSHOT</version> <packaging>jar</packaging> <name>spitballs</name> <inceptionYear>2009</inceptionYear> <properties> <scala.version>2.7.3</scala.version> </properties> <repositories> <repository> <id>scala-tools.org</id> <name>Scala-Tools Maven2 Repository</name> <url>http://scala-tools.org/repo-releases</url> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>scala-tools.org</id> <name>Scala-Tools Maven2 Repository</name> <url>http://scala-tools.org/repo-releases</url> </pluginRepository> </pluginRepositories>

<dependencies> <dependency> <groupId>org.scala-lang</groupId> <artifactId>scala-library</artifactId> <version>${scala.version}</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> <dependency> <groupId>org.specs</groupId> <artifactId>specs</artifactId> <version>1.4.3</version> <scope>test</scope> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.4</version> <scope>test</scope> </dependency> </dependencies> <build> <sourceDirectory>src/main/scala</sourceDirectory> <testSourceDirectory>src/test/scala</testSourceDirectory> <plugins> <plugin> <groupId>org.scala-tools</groupId> <artifactId>maven-scala-plugin</artifactId> <executions> <execution> <goals> <goal>compile</goal> <goal>testCompile</goal> </goals> </execution>

</executions> <configuration> <scalaVersion>${scala.version}</scalaVersion> </configuration> </plugin> </plugins> </build> <reporting> <plugins> <plugin> <groupId>org.scala-tools</groupId> <artifactId>maven-scala-plugin</artifactId> <configuration> <scalaVersion>${scala.version}</scalaVersion> </configuration> </plugin> </plugins> </reporting> </project>

The good news is that Maven is very powerful, and as my project has more dependencies, Maven will take care of downloading them and getting them right. This also means that I don t have to have a bunch of JAR files in my source repository. The bad news is that the Maven pom.xml is a big hairy mess. Good thing there are other build tools.

Ant is to Java build tools as make is to Unix build tools. It s good enough to get most jobs done and bad enough for everyone to complain about it. Scala itself uses Ant as its build system, and the Scala Ant plug-in has been very stable for a very long time. Here s an Ant build script for a generic Scala project:

<project name="Basic Scala Project" default="build" basedir="../"> <property name="base.dir" value="${basedir}" /> <property name="sources.dir" value="${base.dir}/src" /> <property name="build.dir" value="${base.dir}/build//classes.tmp" /> <property environment="env"/> <property name="scala.home" value="${env.SCALA_HOME}" /> <target name="init">

<property name="scala-library.jar" value="${scala.home}/lib/scala-library.jar" /> <path id="build.classpath"> <pathelement location="${scala-library.jar}" /> <pathelement location="${build.dir}" /> </path> <taskdef resource="scala/tools/ant/antlib.xml"> <classpath> <pathelement location="${scala.home}/lib/scala-compiler.jar" /> <pathelement location="${scala-library.jar}" /> </classpath> </taskdef> </target> <target name="build" depends="init"> <mkdir dir="${build.dir}" /> <scalac srcdir="${sources.dir}" destdir="${build.dir}" classpathref="build.classpath" force="changed"> <include name="**/*.scala" /> </scalac> </target> <target name="run" depends="build"> <java classname="test.Test" classpathref="build.classpath"> </java> </target> </project>

Ant scripts are marginally shorter than Maven scripts, but they do not do any dependency management. Ant scripts are about the compilation and packaging tasks, and that s it.7 But there s a Scala task for Ant, and Ant works well with Scala.

Now, if you want the power of Maven with a very concise and amazingly readable syntax, you want Buildr.8 Buildr is a JVM-targeted build tool written in Ruby. I asked Alex Boisvert, a Buildr committer, to convert the previous Maven Project Object Model (POM) file into Buildr, and he came back with the following for build.yml:

scala.specs: 1.4.3 junit: 4.4

and the following for Buildfile:

require "buildr/scala" repositories.remote << "http://www.ibiblio.org/maven2/" repositories.remote << "http://scala-tools.org/repo-releases" desc "Spitball Secure Event-based Messaging" define "spitballs" do project.version = "0.1.0-SNAPSHOT" project.group = "info.spitballs" package(:jar) end

So, if you want concise, readable build files, Buildr is a great tool. It works with Java, Groovy, Scala, and most other things JVM-related, and it s a top-level Apache project, so it s got a track record and a community around it.