Repositorios en Maven

Maven se coordina mediante cuatro elementos, los cuales definen una dirección para un punto específico desde lo general a lo específico.

1. groupId, se refiere al grupo, compañía, equipo u organización, considerando la convención para identificadores de grupo, el cual dicta que estos empiecen con el nombre de dominio de la organización en reversa, esto es com.santander para banco Santander por ejemplo.
2. artifactId, un identificador único para el grupo que permita ubicar al proyecto. Generalmente es el nombre del proyecto
   
3. version, un número específico para cada liberación del proyecto y se recomienda un identificador especial para proyectos en desarrollo (SNAPSHOT), y
4. packaging, define el tipo de proyecto que al final es la salida producida, por defecto es 'jar', el cual produce un paquete .jar.
   

Una vez que se instala el proyecto en el repositorio local de maven, éste queda disponible localmente para su uso en cualquier otro proyecto local. Por ejemplo, así se define la ruta que maven utiliza para almacenar un artefacto:

/<groupId>/<artifactId>/<version>/<artifactId>-<version>.<packaging>

Maven además de instalar el paquete en el repositorio seleccionado, también copia el pom.xml del proyecto en la misma ruta con el mismo nombre del paquete pero con extensión .pom y crea un archivo en la ruta hasta el artifactId llamado maven-metadata.xml con la identificación de grupo, artefacto y versiones disponibles.  Esto ese algo útil para maven puesto que permite la inclusión recursiva de paquetes dependientes (dependencies).  Por ejemplo, si defines una dependencia en el pom de tu proyecto hacia el paquete commons-email-1.1.jar y éste a su vez depende del paquete subethasmtp-smtp-1.2.jar (dependencia transitoria), ambos paquetes se descargan automáticamente a tu repositorio local cuando compilas tu proyecto.  De esta manera maven resuelve las dependencias de forma recursiva y con base a archivos checksum (archivos con mismo nombre pero extensión .md5) descarga lo que no se encuentre localmente.  Así también si varios proyectos locales requieren de las mismas dependencias, estas se copian al paquete del proyecto (en el caso de un war o ear por ejemplo) cuando se instalan en el repositorio.

Así mismo, una dependencia se puede incluir en cierto alcance (scope), por ejemplo pruebas (test), de manera que cuando se ejecute una prueba o todo el conjunto de pruebas del proyecto, se utilice dicha dependencia, pero no al momento de compilar. ejemplo JUnit:
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
            </dependency>
        <dependency>
solo se utilizaría la dependencia al ejecutar una prueba: mvn test -Dtest=MiPruebaTest o el conjunto de ellas: mvn test

Esto obligaría a que cuando se construya el paquete war o ear no se incluya la dependencia.  Otra forma de eviar que se incluya la dependencia en el paquete del proyecto es asignándole un alcance provided scope, el cual le dice a maven que es necesario para compilar, pero no debe se incluido en la construcción final del proyecto. Es útil por ejemplo cuando desarrollas una aplicación web y necesitas el jar de la API de Servlet para compilar, pero no par incluirla en el paquete final.