backward compatibility of Maven 3 to Maven 2. For most projects, upgrading to Maven 3 will not require any adjustments of their project structure. The first beta of Maven 3 saw the introduction of a parallel build feature which leverages a configurable number of cores on a multi-core machine and is especially suited for large multi-module projects. Syntax Maven projects are configured using a Project Object Model (POM), which is stored in a pom.xml-file. An example file looks like: <project> <!-- model version is always 4.0.0 for Maven 2.x POMs --> <modelVersion>4.0.0</modelVersion> <!-- project coordinates, i.e. a group of values which uniquely identify this project --> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1.0</version> <!-- library dependencies --> <dependencies> <dependency> <!-- coordinates of the required library --> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <!-- this dependency is only used for running and compiling tests --> <scope>test</scope> </dependency> </dependencies> </project> This POM only defines a unique identifier for the project (coordinates) and its dependency on the JUnit framework. However, that is already enough for building the project and running the unit tests associated with the project. Maven accomplishes this by embracing the idea of Convention over Configuration, that is, Maven provides default values for the project's configuration. The directory structure of a normal idiomatic Maven project has the following directory entries: The command mvn package will compile all the Java files, run any tests, and package the deliverable code and resources into target/my-app-1.0.jar (assuming the artifactId is my-app and the version is 1.0.) Using Maven, the user provides only configuration for the project, while the configurable plug-ins do the actual work of compiling the project, cleaning target directories, running unit tests, generating API documentation and so on. In general, users should not have to write plugins themselves. Contrast this with Ant and make, in which one writes imperative procedures for doing the aforementioned tasks. Design Project Object Model A Project Object Model (POM) provides all the configuration for a single project. General configuration covers the project's name, its owner and its dependencies on other projects. One can also configure individual phases of the build process, which are implemented as plugins. For example, one can configure the compiler-plugin to use Java version 1.5 for compilation, or specify packaging the project even if some unit tests fail. Larger projects should be divided into several modules, or sub-projects, each with its own POM. One can then write a root POM through which