Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

Introduction to Apache Maven 2

Sing Li (, Author, Wrox Press
Photo of Sing Li
Sing Li is a consultant and an active author with more than two decades of industry experience. He has contributed to Professional Apache Geronimo, Beginning JavaServer Pages, Professional Apache Tomcat 5, Pro JSP - Third Edition, Early Adopter JXTA, Professional Jini, Beginning J2ME: From Novice to Professional, Third Edition, Professional Apache Geronimo, and numerous other books. Sing also writes for technical magazines and participates in open source communities. He is an evangelist of the open source, VOIP, and P2P movements. You can reach Sing at

Summary:  Modern software projects are no longer solely monolithic creations of single local project teams. With the increased availability of robust, enterprise-grade open source components, today's software projects require dynamic collaboration among project teams and often depend on a mix of globally created and maintained components. Now in its second generation, the Apache Maven build system -- unlike legacy build tools created before the Internet-enabled era of global software development -- was designed from the ground up to take on these modern challenges. This tutorial gets you started with Maven 2.

Date:  19 Dec 2006
Level:  Intermediate

Activity:  152623 views

Understanding the Maven 2 dependency management model

You need to understand how the Maven 2 dependency management model works before you can make use of Maven 2 effectively.

The dependency management model is adapted for projects whose software components (called modules) might be developed by different project teams. It supports continuous independent development and refinement of all dependent modules.

This team collaboration scenario is the norm with open source projects founded and maintained over the Internet and is becoming more prevalent in corporate circles where in-house development meets the open source or the outsourced world.

Resolving project dependencies

The Maven 2 dependency management engine helps resolve project dependencies during the build process.

Maven local and remote repositories

Your Maven 2 local repository is a directory on your disk, typically located at HomeDirectory/.m2/repository. This repository acts as a high-performance local cache, storing any artifacts downloaded as a result of dependency resolution. Remote repositories are accessed over the network. You can maintain a list of remote repositories to use in your settings.xml configuration file.

In practice, dependencies are specified in <dependencies> elements within a pom.xml file and are fed into Maven as part of the POM.

Project dependencies are stored on repository servers (simply called repositories in Maven terminology). Successful dependency resolution depends on finding the required dependent artifact from a repository that contains the artifact.

Maven configuration through settings.xml

You can specify configuration properties that affect Maven operation in a settings.xml file. The default settings file is MavenInstallationDirectory/conf/settings.xml. Maven 2 users can maintain UserHomeDirectory/.m2/settings.xml to override some configuration properties. See the Maven settings reference for more information on the configurable settings.

Based on the project dependency information in the POM, the dependencies resolver attempts to resolve the dependencies in the following order:

  1. Your local repository is checked for the dependency.
  2. A list of remote repositories is checked for the dependency.
  3. Failing 1 and 2, an error is reported.

By default, the first remote repository contacted in step 2 is a worldwide-accessible centralized Maven 2 repository containing artifacts for most popular open source projects. In the case of in-house development, you can set up additional remote repositories containing release artifacts from in-house developed modules. The <repositories> element in settings.xml can be used to configure these additional remote repositories.

Single copy of artifact enforced

When you use Maven 2 for your project builds, the dependency resolution via a centralized repository ensures that only a single copy of a dependent artifact exists, regardless of how many projects or subprojects reference it. This is a vital property for multimodule project builds because inclusion of multiple copies of artifacts can lead to project consistency and integrity problems.

3 of 15 | Previous | Next


Zone=Java technology, Open source
TutorialTitle=Introduction to Apache Maven 2