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.
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.
Based on the project dependency information in the POM, the dependencies resolver attempts to resolve the dependencies in the following order:
- Your local repository is checked for the dependency.
- A list of remote repositories is checked for the dependency.
- 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.




