Skip to main content
Blog

State of the build

By 28 november 2013januari 30th, 2017No Comments

I’ve been using Maven for almost all projects I’ve worked on since the release of version 2.0 in 2005. Its dependency management, release plugin and “convention over configuration” approach were definite improvements compared to Ant and most of the issues I’ve encountered had to do with third-party plugins.

Since that time several other build tools have come into existence. How do these compare against Maven?

A replacement for Maven should at least provide these features:

  • Dependency management with an external (Maven) repository
  • Generate jar, war and ear files
  • Provide a simple way to release projects
  • Eclipse support
  • Jenkins support

Ant + Ivy

Ivy (http://ant.apache.org/ivy) is an extension for Ant that adds dependency management, allowing Ant to use Maven repositories. To use it, you need to add a new ivy.xml file that contains the dependencies.(http://ant.apache.org/ivy/history/latest-milestone/tutorial/start.html) An Ant task can then be used to copy the required dependencies to a known location, or generate a build path.
Ant has no problems generating jar, war and ear files, but setting up tasks for them requires more XML than Maven.There is no drop-in replacement for Maven’s release plugin, but it’s possible to create a task for it using Maven Ant Tasks (http://maven.apache.org/ant-tasks) in combination with tasks for your version control system.
Eclipse has had support for Ant for a long time and the same goes for Jenkins, which is no wonder as Ant has been around since 2000.
Although it’s a useful addition to Ant, I wouldn’t use it as a replacement for Maven. Configuring Maven plugins is easier and less work than writing Ant tasks.

Simple Build Tool (sbt)

Simple Build Tool (http://www.scala-sbt.org) is a build tool for Scala and Java. It makes use of Ivy as well and can use Maven repositories for its dependencies, but managing dependencies for multiple modules requires some more work. It uses Scala for its build definition, making it easy to add new tasks, assuming that you’re already familiar with Scala. Plugins can also be developed in Scala, and there is already a plugin for releasing projects (https://github.com/sbt/sbt-release).
Jar files are well supported, but war or ear files but require a lot of code in a sbt build file(http://www.scala-sbt.org/release/docs/Detailed-Topics/Artifacts).
Like Maven, there is a plugin that allows sbt to generate the Eclipse project configuration, but I would have preferred it if this could have been done from within Eclipse instead. A plugin for Jenkins is provided as well.

The focus of sbt is on Scala and it shows. It might be worthwhile to investigate this tool for your Scala projects, but for pure Java projects I wouldn’t use it.

Buildr

According to the website (http://buildr.apache.org) Buildr is a build tool for Java and other JVM-based languages such as Groovy and Scala. It’s based on the Ruby build tool Rake, and supports Maven repositories.
It’s pretty easy to generate jar, war and ear files with it, and it even has a release plugin like Maven.
Buildr provides plugins to create a configuration based on an Eclipse project, and generate a basic Eclipse project based on a build file, but like sbt there is no support for it within Eclipse. There is also no Buildr plugin for Jenkins. It would still be possible to use Jenkins, but it’s a lot less convenient than Maven.
Buildr uses Ruby for its build file, which is its biggest drawback in my opinion. As a language, Groovy would have been more suited for Java projects than Ruby, and the introduction of Ruby gems doesn’t help either.

Gradle

Gradle (http://www.gradle.org) is a build tool that uses Groovy for its build file. Its out-of-the-box support for generating jar, war and ear files is similar to Maven, and it adopts a similar convention-over-configuration approach.
A Maven-like release plugin is available (https://github.com/townsfolk/gradle-release), as well as a plugin to generate an Eclipse project.
Plugins that add Gradle support exists for Eclipse (https://github.com/spring-projects/eclipse-integration-gradle/) and Jenkins .
Gradle also offers good support for Ant, allowing Ant tasks to be included in the build file (http://www.gradle.org/docs/current/userguide/ant.html). It might even be easier to script Ant tasks in Gradle than in Ant.

Conclusion

Maven has had a lasting influence on build tools with its dependency management. All the current build tools offer similar dependency management and can use existing Maven repositories.

It’s also interesting to note that the current trend is to use a domain-specific language (DSL). Maven 3 was supposed to offer this as well, but this was eventually cut. Work on this still continues, but for now outside the Maven project (https://github.com/tesla/tesla-polyglot).

Of these four tools, Gradle is the closest competitor to Maven. Like Maven, there is a wide selection of plugins already available for it and even more if Ant task are included. Support for development environments and continuous integration servers is equal to Maven and more complete than either sbt or Buildr.

Switching from Maven probably won’t provide much advantages, but for new projects it is well worth considering.