Gestión de dependencias

En este nuevo post vamos a explicar un poco más en profundidad cómo funciona la gestión de dependencias en Maven y como se manejan dichas dependencias en Eclipse con el plugin m2eclipse.

Dependencias

Como ya hemos visto, cuando definimos las dependencias hay que indicar:

  • groupId
  • artifactId
  • version
  • scope (que puede ser compile | test | runtime…).

Por ejemplo, para incluir la dependencia del artefacto que hemos generado en los ejemplos de los anteriores post, escribiríamos:

Si queremos añadir la dependencia a Log4j, podemos visitar http://mvnrepository.com/ por ejemplo, buscar log4j y elegir la versión que nos interese:

mvnrepository

mvnrepository.com

Desde el plugin m2eclipse se pueden añadir fácilmente las dependencias, pulsando botón derecho sobre el proyecto “Maven>>Add Dependency”, o desde el editor del pom.xml. Se escribe el nombre del paquete o la librería y se selecciona la que queramos, indicamos el scope que necesitamos y pulsamos “Ok”.

Asistente para añadir dependencias

Asistente para añadir dependencias

El scope

Hay 6 tipos de scope:

  • compile → Por defecto. Las dependencias de compilación están disponibles en todos los classpaths de un proyecto. Por otra parte, esas dependencias se propagan a proyectos dependientes
  • provided → Es similar a la compilación, pero indica que espera encontrar la dependencia del JDK o un contenedor en tiempo de ejecución. Por ejemplo, al crear una aplicación web Java Enterprise, se debe establecer la dependencia de la APIs Servlet y Java EE relacionadas con el alcance provided ya que el contenedor web proporciona esas clases. Este ámbito de aplicación sólo está disponible en la compilación y test, y no es transitiva
  • runtime → Indica que la dependencia no se necesita para compilar, pero si en tiempo de ejecución. Está en el classpath de tiempo de ejecución y test classpaths, pero no en el de compilación.
  • test → Indica que esta dependencia no es necesaria para el uso normal de la aplicación y sólo está disponible para las fases de compilación y ejecución de los test.
  • system → Similar a provided con la excepción de que tienes que proporcionar el JAR de manera explícita. El artefacto está siempre disponible y no se encuentra en los repositorios.
  • import → Únicamente utilizado en dependencias de tipo pom en el apartado “" . De este modo se importan las dependencias definidas en otro pom
Versiones y rangos de versiones de las dependencias

Respecto a la versión a utilizar, se puede especificar una versión una versión en concreto de una librería, por ejemplo:

Si se define una dependencia de tipo SNAPSHOT, se está indicando que se está trabajando con una librería en desarrollo, maven comprobará si hay versiones SNAPSHOT más actualizadas en el repositorio, y en caso de que así sea, se la descargará. Normalmente dicha librería formará parte de otros proyectos que estemos implementando y la iremos actualizando en el repositorio de desarrollo. Cada vez que actualizamos una versión SNAPSHOT, maven almacena en el repositorio cada una de estas versiones, sustituyendo “SNAPSHOT” por el timestamp del momento en el que la actualizamos. De este modo, puede determinar cual es la más actual.

También se pueden especificar rangos, de manera que intente recuperar la versión más alta que esté dentro del rango:

Para dejar el rango abierto, de modo que no limitemos por uno de los extremos el rango, esto se hace del siguiente modo:

En el ejemplo anterior, estamos indicando que como mínimo necesitamos la versión “1.0”, pero que si aparece la versión “1.77”, nos la descargue. Si quisiéramos dejar abierto el rango, como en el caso anterior, pero únicamente hasta cierto límite, podemos hacer lo siguiente:

Con esto estamos dejando el rango abierto, pero solo hasta la versión “1.14” como mucho.

Excluir librerías

Como vimos en anteriores post cuando hablamos de las dependencias transitivas, cuando introducimos una dependencia, y ésta a su vez dependen de otras librerías, Maven descarga todas ellas, lo vimos con el ejemplo de “junit4.11”:

Vemos que esta dependencia, añade también el “hamcrest-core-1.3.jar”:

Detalle de las dependencias

Detalle de las dependencias

Para excluir una dependencia, podemos pinchar con el botón derecho del ratón sobre la librería en cuestión, desde el explorador de paquetes de Eclipse, y en el menú emergente seleccionamos “Maven>>Exclude Maven Artifact”, nos aparecerá una ventana donde podremos seleccionar el pom.xml y al dar a aceptar, nos habrá eliminado la dependencia. Si analizamos el pom.xml, veremos lo que ha realizado:

Como se puede ver, m2eclipse ha añadido el nodo “” donde se puede excluir la/s librería/s que nos interese. De este modo podemos evitar conflictos, por ejemplo, si en el caso anterior ya estamos usando la versión 1.9 de la librería “hamcrest-core”, y al añadir la dependencia a junit, por dependencia transitiva, nos descarga la versión 1.3, esto puede dar lugar a errores. Así que la excluimos.

Por supuesto, en lugar de usar Eclipse, podemos editar directamente el pom.xml, como se ha mostrado anteriormente.

Bueno, aquí termina la explicación. En el siguiente post hablaremos sobre como manejar los proyectos multimódulo con Maven y su uso en Eclipse

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *