Introducción de dependencias

La otra funcionalidad básica que ofrece Maven es la gestión de las dependencias. Cualquier proyecto depende de código desarrollado por terceros: desde JUnit para ejecutar pruebas unitarias a librerías para gestionar logs o frameworks como Spring para facilitar el desarrollo de nuestra aplicación. Maven se encarga de descargar y organizar estas dependencias por nosotros para evitar que tengamos que hacerlo manualmente. Para ello se basa en tres elementos: repositorios remotos, las dependencias definidas en pom.xml y el repositorio local en ${user.dir}/.m2.

Repositorios remotos

En estos repositorios los desarrolladores suben las dependencias. Existe un repositorio por defecto, Maven Central, que es donde están subidas la mayoría de dependencias. No obstante, si tenemos dependencias privadas (por ejemplo, código que no queremos hacer público) podemos utilizar repositorios instalados en nuestra propia organización. Esto último también resulta útil para cachear las dependencias de Maven Central y conseguir que se descarguen más rápido a las máquinas de nuestros desarrolladores.

Los repositorios están organizados en directorios según el groupId, artifactId y version del proyecto. La estructura de directorios de Maven Central la puedes consultar en http://repo.maven.apache.org/maven2/

Ejercicio: Busca la referencia a un proyecto con groupId log4j y artifactId log4j dentro de Maven Central. Fíjate en la información que contiene el fichero maven-metadata.xml, la forma en la que se accede a las distintas versiones y los ficheros que hay correspondientes a cada versión.

Dependencias definidas en pom.xml

En el fichero pom.xml del proyecto se configuran las dependencias del mismo dentro del elemento <dependencies>. Un ejemplo es:

  ...
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
  ...

Cada dependencia se identifica por su groupId, su artifactId y su versión. Además, para cada dependencia se le asigna un scope, que se refiere a en qué momento debe estar disponible la dependencia. Los scopes más habituales son los siguientes:

• compile: Es el scope por defecto. Indica que la dependencia es necesaria para la compilación del proyecto y ejecución del proyecto. Si estoy generando un WAR se añadirá dentro de éste. Lo normal es que este sea el scope de casi todas las dependencias.
• test: Indica que la dependencia es necesaria exclusivamente para ejecutar las pruebas, pero no para usar el proyecto. Un ejemplo de dependencia con scope test es JUnit, que se usa para las pruebas, pero no es necesaria para que nuestro proyecto funcione.
• runtime: Indica que la dependencia no es necesaria para la compilación, pero si para su ejecución (incluidas las pruebas).
• provided: Indica que la dependencia es necesaria para la compilación del proyecto, pero que para la ejecución del proyecto espera que esté disponible en el entorno de ejecución. Este es el tipo de scope que se utiliza para el Servlet API en una aplicación web pues es Tomcat quien la proporciona en tiempo de ejecución. A diferencia de compile, si estoy generando un WAR estas dependencias no se añadirán dentro de éste.

Puedes encontrar más información sobre el mecanismo de dependencias de Maven en: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Ejemplo: Para añadir al pom.xml del proyecto la dependencia a la versión 1.2.17 de log4j habría que añadir lo siguiente:

…
<dependency>
     <groupId>log4j</groupId>
     <artifactId>log4j</artifactId>
     <version>1.2.17</version>
     <scope>compile</scope>
</dependency>
...

Repositorio local en ${user.dir}/.m2

En esta carpeta es donde maven guarda y organiza las dependencias que se va descargando en nuestra máquina. Todos los JAR que hay ahí están disponibles para cualquier proyecto maven que utilicemos en nuestra máquina. Ahí es donde va a parar también nuestros JAR cuando ejecutamos la fase install.

Ejercicio: Una vez añadida la dependencia a log4j, compila el proyecto y observa cómo se descarga la dependencia. Busca en ${user.dir}/.m2 el sitio donde se ha descargado la dependencia.

Ejercicio: Ejecuta mvn install y busca en ${user.dir}/.m2 dónde se ha copiado el JAR de nuestro proyecto. Ahora ese JAR estará disponible para cualquier otro proyecto que construyamos en nuestra máquina.

Ejercicio

1. Crear el fichero log4j.properties en la carpeta main/resources con este contenido:

   # Root logger option
   log4j.rootLogger=INFO, stdout
   # Direct log messages to stdout
   log4j.appender.stdout=org.apache.log4j.ConsoleAppender
   log4j.appender.stdout.Target=System.out
   log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
   log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
   

2. Modificar App.java para incluir un Logger

   import org.apache.log4j.*; 
   …
   static Logger log=Logger.getLogger(App.class); 
   …
   log.info("Returning 1");
   

3. Testear el proyecto para observar el log

   mvn test