Home > Articles > Programming > Java

Java Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

Managing Java Build Lifecycles with Maven

Last updated Mar 14, 2003.

You’ve undoubtedly heard me talk about two primary contenders in the Java build tool space: Ant and Maven, but in actuality categorizing Maven as simply a build tool is doing it a disservice. Maven should rather be categorized as a project management or a project lifecycle management tool. Maven is meant to take control of the building, testing, and packaging of your application: your responsibility is to describe your project to Maven and its job is to manage its build lifecycle. The process of describing your project involves defining a project management file, called a POM file, placing resources in the appropriate locations, and telling Maven about dependencies upon which your application depends.

Probably the best known feature of Maven is its dependency management and its support for distributed repositories. In short, you tell Maven what libraries your application uses, such as Hibernate version 3.3.2 or Spring version 2.5.6 and it goes to the Internet to one of its repositories, downloads the correct versions of JAR files, and then compiles your application with those JAR files. Furthermore, if you are building a WAR or EAR file, it builds those artifacts with the included dependencies in the correct locations, for example it places JAR files in the WEB-INF/lib folder in the case of a WAR file. And if that were not easy enough, you only need to know about the dependencies that you need, not the dependencies that your dependencies need (because Maven finds those recursively.)

With respect to lifecycle, Maven forces you to think more in terms of lifecycle phases than in terms of tasks that you want to accomplish. For example, the following are the default lifecycle build phases that Maven lists on its website (which is really a subset of the complete lifecycle listed here)

  • validate: validate the project is correct and all necessary information is available
  • compile: compile the source code of the project
  • test: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
  • package: take the compiled code and package it in its distributable format, such as a JAR.
  • integration-test: process and deploy the package if necessary into an environment where integration tests can be run
  • verify: run any checks to verify the package is valid and meets quality criteria
  • install: install the package into the local repository, for use as a dependency in other projects locally
  • deploy: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

Thus, instead of thinking about compiling your source files with <javac>, constructing a JAR with <jar> for your source code, building a WAR file with <war>, including your dependencies, as you do with Ant, you instead thing about packaging your application and, because your POM file tells Maven that your application is WAR file, it knows that it needs to compile your source, build JAR files, find your dependencies, and assemble your WAR file. Finally, it has hooks in place to execute unit tests and integration tests if you have them written.

The only big complaint that I have heard about Maven is that it does not allow you the freedom to do things the way that you want to do them, or rather it makes it more difficult to do things the way you want to do them. For example, if you want to store your Java source files in the following subdirectory in your projects:

src/main/java

It is very easy to use Maven. But if, for some reason you do not like “main” (and there is a “test” which is why there is a “main” and there is a “webapp” which is why there is a “java”) then you have to jump through hoops to make Maven work in your environment. My personal opinion is that the dependency management and the lifecycle abstraction that Maven provides far outweighs any personal preference I may have for the placement of my source files. And, as a friend of mine, Daniel, probably stated far more articulately than I shall do here: if you embrace the system it can make your project management much easier – if you fight it you can eventually make it do what you want, but use th tool for what it is good for.

Save To Your Account