---
 Introduction to repository definitions and artifact resolution
 ---
 John Casey
 ---
 2006-08-23
 ---
  
~~ Licensed to the Apache Software Foundation (ASF) under one
~~ or more contributor license agreements.  See the NOTICE file
~~ distributed with this work for additional information
~~ regarding copyright ownership.  The ASF licenses this file
~~ to you under the Apache License, Version 2.0 (the
~~ "License"); you may not use this file except in compliance
~~ with the License.  You may obtain a copy of the License at
~~
~~   http://www.apache.org/licenses/LICENSE-2.0
~~
~~ Unless required by applicable law or agreed to in writing,
~~ software distributed under the License is distributed on an
~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
~~ KIND, either express or implied.  See the License for the
~~ specific language governing permissions and limitations
~~ under the License.

~~ NOTE: For help with the syntax of this file, see:
~~ http://maven.apache.org/doxia/references/apt-format.html

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.

*Goals

  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.

~~Repository list construction (for resolution)
~~~~Repository sources (local vs. default vs. inheritance vs. transitive POMs)
~~~~Preserving the authority of the POM which declares the artifacts
~~~~Local-wins priority (during inheritance AND transitive dependency resolution)
~~~~Keeping the super-POM repositories last in line (ensuring their default status)

~~The net effect: a sample walkthrough