Most Java projects start with a single Ant file used to configure the build environment—setting library dependencies, output directories, and the like—and then to perform various build-related tasks.

One upon a time, Apache Turbine was one such project, but Turbine also depended on other Apache projects, each with its own Ant file. Maven 1 was created to solve the problem of working with a project that makes use of several other, independent subprojects. Maven has since grown to provide sophisticated project management features for any Java project, including a uniform build environment, with dependency tracking between the various sub-projects.

Maven 2 was a complete re-write of Maven 1, with the chief aim of making the tool easier to use, and its use more consistent across different kinds of projects.

At the heart of a Maven project is the project object model (POM), expressed in an XML file. Eric Redmond's recent JavaWorld article, The Maven 2 POM Demystified, provides a quick introduction to the Maven 2 POM:

A project contains configuration files, as well as developers involved and roles they play, the defect tracking system, the organization and licenses, the URL where the project lives, the project's dependencies, and all the other little pieces that come into play to give code life. A project is a one-stop shop for all things related to it. In fact, in the Maven world, a project need not contain any code at all, merely a pom.xml.

The article describes how the Maven 2 POM specifies project metadata, as well as helps manage dependencies by linking to a common library repository from the POM:

Dependency management has a long tradition of being a complicated mess for anything but the most trivial of projects. "Jarmageddon" quickly ensues as the dependency tree becomes huge, complicated, and embarrassing to architects who are scorned by new graduates who "totally could have done it better." "Jar Hell" follows, where versions of dependencies on one system are not quite the same versions as those used for development; they have either the wrong version or conflicting versions between similarly named JARs. Hence, things begin breaking and pinpointing why proves difficult. Maven solves both of these problems by having a common local repository from which to link to the correct projects, versions and all.

Subsequent parts of the article describe the ability for one project to inherit properties of another project, and project aggregation—a feature that lets you create projects composed of other Maven projects. Finally, Redmond's article focuses on setting up a build environment with Maven 2, as well as specifying project reporting, such as JavaDoc documentation or dependency analysis information.

In what situations do you feel Ant files just don't cut it any more in your projects? And what tools do you use to manage more complex project configuration?