Introduction to Repository definitions and artifact resolution

As you no doubt know by now, artifacts are a central concept to Maven. Since artifacts are referenced in abstract terms (groupId/artifactId rather than file path), they must be available in the Maven repository system in order for the build process to resolve them. This really amounts to putting the referenced artifacts into a Maven repository.

To promote flexibility in the configuration of your build environment, Maven allows multiple repositories to be defined from which artifacts can be resolved. Repositories are always defined in the POM, but since POMs can inherit from one another, and POM dependencies are resolved transitively, predicting which repository will be used to resolve a particular artifact can be daunting.

This document will attempt to explain the rules involved with constructing repository lists for resolving artifacts referenced in various parts of the build process, and eliminate - or at least, reduce - the potential for confusion when it comes to artifact resolution.


The artifact resolution process in Maven has a couple of central goals which should help make the build process as flexible and powerful as possible. They are:

  • Allow the local POM (the one being built) to have the first opportunity to control resolution.

    NOTE: In the case of an inheritance hierarchy, the ancestor POMs are appended to the current repository list in inside-out order.

  • Allow the declaring-POM (the one declaring the dependency, in the case of transitivity) the second opportunity.
  • Default to the repositories defined in the super-POM for resolution.