Repositorios Maven: Nexus

Como dijimos en nuestra pequeña introducción a Maven, el lugar donde se va a almacenar nuestro software son los llamados repositorios.

La distribución de Maven por defecto se descarga los artefactos del repositorio principal de Maven. Si bien esto a nivel personal es factible, cuando varios desarrolladores se tienen que descargar los mismos jars pesados una y otra vez es un despilfarro de ancho de banda considerable.

Por ello se suele instalar un repositorio propio. Podemos usar un servidor web sirviendo los directorios del repositorio pero no nos proporciona características muy deseables como son: ejercer de intermediario con otros repositorios, facilidades de navegación, facilidades de búsqueda o formularios para subir artefactos entre otras. Por ello existen otras soluciones que nos facilitan la vida, todas ellas libres y que son comparadas en esta matriz de comparación de gestores de repositorios Maven ( en inglés).

Yo en su día probé Artifactory del que además tenemos esta guía de utilización de Artifactory. Sobre Archiva también he encontrado esta muy completa guía de utilización de Archiva (en tres partes II y III). Por eso (entre otras cosas) me he decidido a probar Nexus.

Nexus viene preparado para levantar un servidor y su instalación de esa manera está bien documentada en Maven: The definitive guide que es como nos recomiendan empezar en la web de Nexus. Pero yo quería aprovechar el Tomcat que tengo corriendo en mi servidor Xubuntu por lo que decidí instalar el war que se nos ofrece en la sección de descargas de Nexus. Los pasos que seguí son sencillos:

• Descargué el war (nexus-1.1.1.war en ese momento) y lo renombré a nexus.war (para que la aplicación la despliegue como nexus y no nexus-1.1.1).
• Desplegué el war a través de la aplicación manager de Tomcat.
• Modifiqué el archivo plexus.properties dentro del directorio de la aplicación desplegada (en mi caso /usr/share/tomcat5.5/webapps/nexus/WEB-INF) para añadirle una ruta válida. Yo puse: nexus-work=/home/nexus/sonatype-works/nexus
• Por último y aunque según la documentación no era necesario, añadí al script de arranque de Tomcat (/etc/init.d/tomcat5.5) la variable de entorno para indicarle el directorio de nexus. Al final de la línea que empieza por JAVA_OPTS se añade -DNEXUS_HOME=/home/nexus

Con esto y tras reiniciar el Tomcat, ya podemos apuntar nuestro navegador a la aplicación recién instalada (en mi caso http://server:port/nexus/). Podemos ver la página de Nexus que nos recibe:

Sólo con esto ya podemos ver que Nexus nos va a proporcionar búsqueda de artefactos, así como algunas posibilidades de suscripción mediante RSS (por ejemplo a nuevos artefactos subidos). Para poder configurar Nexus, debemos identificarnos como administrador («admin» con «admin123» por defecto). Lo primero que debemos configurar es:

• Por seguridad modificar la contraseña del administrador (menú «Change Password»).
• Configurar el servidor de correo (para correos de recuperación de contraseña). En el menú «Server» bajo «Administration».
• Habilitar el indexado de repositorios remotos. En el menú «Repositories» bajo «Administration», pinchando sobre los repositorios de tipo proxy. Pondremos a true el campo «Download Remote Indexes» (Nexus se baja los índices de esos repositorios y puede tardar un rato). De esta manera podemos buscar artefactos que se encuentren en los repositorios remotos y descargarlos a nuestro repositorio

Finalmente tendríamos que configurar nuestro Maven local para que acceda a nuestro nuevo repositorio. Para ello introduciremos en el archivo de configuración de Maven (settings.xml en el directorio .m2 dentro de nuestro directorio personal) las líneas necesarias para reflejar nuestro repositorio:

    <mirror>
      <id>Nexus</id>
      <mirrorOf>central</mirrorOf>
      <name>Nexus Public Mirror.</name>
      <url>http://server:port/nexus/content/groups/public</url>
    </mirror>

Esto es todo por esta primera entrada sobre Nexus. En próximas entradas hablaré de algunas características de Nexus como son los grupos (fijaros ese groups en la ruta al repositorio en el código anterior) o la seguridad.

Presentando Maven. Explicación básica.

Voy a presentar una herramienta libre muy utilizada en el mundo Java: Maven. Pretendo hacer una pequeña introducción para resaltar ideas.

Básicamente Maven es una herramienta de generación y gestión de proyectos Java. Uno de sus puntos fuertes es la gestión de dependencias, y es una de las cosas que hicieron que se adoptase en muchos proyectos en lugar de Ant.

Maven promueve una estructura de proyecto determinada, ya que se basa en el principio «convención sobre configuración», es decir, que si hacemos las cosas de una forma determinada nos ahorramos configurar esas cosas. Sin duda seguir esa estructura nos facilitará las cosas.

A pesar de la creencia popular de que Maven es una especie de Ant, o un Ant ampliado, la verdad es que se parecen en poco. Ente esas similitudes destaca el detalle de que la descripción del proyecto está en un xml, que en Maven se llama pom.xml (frente al build.xml de Ant).

Otro concepto importante dentro de Maven es el de repositorios. Un repositorio es un almacén de paquetes (archivos jar habitualmente) ordenados de forma inequívoca incluyendo la versión. Maven se descarga a un repositorio local (bajo .m2 en el directorio del usuario) todas las dependencias y plugins que va necesitando. Esta descarga hace que las primeras ejecuciones puede ser bastante largas.

Pero para hacernos una primera idea de cómo funciona Maven, vamos a ver cómo sería un archivo pom.xml típico.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.tcymu.maven</groupId>
  <artifactId>test1</artifactId>
  <name>test1</name>
  <version>0.0.1-SNAPSHOT</version>
  <dependencies>
      <dependency>
          <groupId>log4j</groupId>
          <artifactId>log4j</artifactId>
          <version>1.2.15</version>
      </dependency>
  </dependencies>
</project>

Las partes importantes sería la definición de groupId que cumple una función similar a la de un paquete Java. artifactId sería el nombre de este artefacto (jar) en el repositorio. Como es de suponer version define la versión del artefacto. Y bajo dependencies aparecen las dependencias, que como se puede ver constan precisamente de un groupId, un artifactId y una version.

Con esto y si hemos seguido la estructura de paquetes que sugiere Maven, compilaríamos el proyecto (incluyendo la descarga de dependencias) con una simple línea:

mvn compile

Con compile le estamos indicando una fase. Algunas de las otras fases disponibles en Maven son: clean (limpia todo lo que ha generado), package (genera un jar), install (instala el jar en el repositorio local) o deploy (instala el jar en un repositorio remoto).

Hay que señalar que al ejecutar una fase se ejecutan todas las anteriores (para hacer un package primero hace un compile). Además ejecutar una fase significa realmente ejecutar una serie de tareas (goals) de una serie de plugins determinados.

¿Y qué es un plugin en Maven?. Pues prácticamente todo. Todas las tareas que ejecuta Maven son plugins. Así por ejemplo el compilar es llamar a la tarea compile del plugin compiler. Se puede llamar a una tarea de un plugin directamente mediante:

mvn compiler:compile (notación plugin:goal)

Existe una gran cantidad de plugins para Maven. Muchos de ellos con multitud de tareas.

Con esta introducción he intentado aclarar un poco los conceptos sobre Maven. Que realmente en un principio pueden ser algo confusos. Como en otras entradas utilizaré Maven, seguro que se irán aclarando más vuestras dudas.