Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Maven 2 is a Java project build and management tool centered on a project descriptor named pom.xml. It reads the Project Object Model (POM), resolves libraries the project depends on, and runs plugin goals through an ordered build lifecycle. The POM describes the project and its configuration; plugins perform much of the concrete build work.

This guide explains Maven 2’s core ideas while distinguishing its history from current Apache Maven documentation, which describes the concepts but is not a complete Maven 2 manual.

What Maven 2 does

Maven helps organize a project’s build and management tasks around a shared description of the project. The Apache Maven Project describes Maven as building a project using its POM and a set of plugins. The POM is declarative: it records project identity, dependencies, and build configuration, while plugins provide the goals that carry out specific actions.

The shift to the POM file is part of Maven 2’s history. An Apache-hosted archived guide records that Maven 1 used project.xml, whereas Maven 2 used pom.xml; it also says goals or plugins were configured in pom.xml rather than in a separate maven.xml. See the archived Maven POM introduction.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

What a POM contains

A POM is an XML file containing project information and build configuration. The Apache Maven Project calls it “the fundamental unit of work in Maven” in its current Introduction to the POM. A minimal descriptor identifies the project with three coordinates:

  • groupId: the group or organization namespace for the artifact.
  • artifactId: the project or artifact name within that group.
  • version: the version of that artifact.

Together, these coordinates identify an artifact in groupId:artifactId:version form. The current POM guide’s minimal example also includes a project root and modelVersion set to 4.0.0. It says that, when packaging is omitted, the current default is jar; these are current-guide details, not assertions verified against every Maven 2 installation.

<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>sample-app</artifactId>
  <version>1.0.0</version>
</project>

A project can add dependencies, plugins and their configuration, profiles, and descriptive metadata. Maven also supplies inherited defaults through the Super POM. The current POM introduction lists conventional locations including src/main/java for application source, src/test/java for test source, and target for build output. A project may change configuration rather than repeat every default.

How Maven resolves dependencies

A dependency is another artifact a project needs. Maven can retrieve artifacts from repositories and generally includes dependencies of those dependencies, a behavior called transitive dependency resolution. This lets a project declare its direct libraries without listing every library deeper in the dependency chain.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Transitive resolution makes version selection important. The current Apache dependency mechanism guide explains that if dependency paths request different versions, the nearer dependency can be selected; declaring a dependency directly can affect that result. A project with unexpected versions should inspect the resolved dependency tree rather than assume that every requested version is included unchanged.

Centralizing dependency versions

The dependencyManagement section can centralize versions and related dependency information, especially in a parent POM inherited by multiple projects. Child POMs can then declare which dependencies they use without repeating the managed version each time. Management does not, by itself, add every listed dependency to a child project: the child still needs to declare a dependency to use it.

Forcing a centrally managed version can create incompatibilities if another library expects a different one. When diagnosing a conflict, the POM reference recommends inspecting the resolved dependency tree. Use version management to make choices consistent, then verify that the resulting combination works for the project.

Repositories: retrieving versus publishing artifacts

Maven uses a local repository cache and configured remote repositories to find artifacts. According to the current POM introduction, a minimal POM inherits the default Central repository through the Super POM. This is how a build can obtain libraries it needs without storing every dependency in the project itself.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Retrieving dependencies and publishing a project’s own built artifact are separate tasks. Repository configuration for dependencies is distinct from distributionManagement, which configures where a project’s artifacts are published. The current POM Reference documents the distinction.

How the build lifecycle and plugins fit together

Maven’s build lifecycle is an ordered structure for build work. A lifecycle phase names a point in that process; a plugin supplies goals that perform concrete actions, and plugin goals can be bound to lifecycle phases. When Maven is asked to run a phase, the lifecycle organizes the bound work leading up to it.

The project’s packaging and plugin configuration affect what happens at each phase. The POM reference covers plugin configuration, while the official Maven documentation index treats the build lifecycle and plugin configuration as separate core guide topics. Exact phase bindings can vary with configuration and packaging, so a generic phase list should not be treated as a guaranteed description of every Maven 2 build.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

How parent POMs and modules differ

Maven supports both inheritance and aggregation, but they solve different problems:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Inheritance: a child POM has a parent and can inherit shared configuration from it.
  • Aggregation: a project gathers modules so they can participate in a coordinated multi-module build.

A project can use these relationships to share settings and coordinate work across several modules. Neither relationship changes the role of dependencyManagement: it manages dependency information and versions, but does not automatically add managed libraries to a module’s dependency list. The current POM introduction and POM Reference describe these project relationships.

Reading Maven 2 documentation today

Maven 2’s pom.xml-centered model remains useful for understanding Maven projects. However, the linked live Apache pages are current documentation, not a complete historical reference for Maven 2. Treat their descriptions of the POM, repositories, dependency resolution, and plugins as guidance on the enduring concepts; consult archived Maven 2-era documentation when an exact historical behavior or default matters.

The archived Apache page supports the specific Maven 1-to-Maven 2 change from project.xml to pom.xml. The current Introduction to Apache Maven provides the high-level account of Maven as a POM-and-plugin-based build tool.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.