Archiva: gestión de repositorios maven (I)

0
52923

Archiva: Gestión de repositorios maven (I).

1. Introducción

Archiva (http://maven.apache.org/archiva) pertenece al conjunto de proyectos desarrollados por el equipo de Jakarta Maven, como Continuum, SCM, Wagon, JXR, Doxia … Básicamente es una herramienta de gestión de repositorios maven. Entre las funcionalidades que podemos destacar y que veremos más adelante en el tutorial, podemos citar: gestión de control de acceso a los repositorios definidos, cacheo de artefactos configurando proxys a repositorios remotos y gestión y mantenimiento de repositorios maven 1.x y 2.x (indexación, búsquedas, informes …).

2. Instalación

El equipo de maven proporciona dos formas de instalar Archiva. Como una aplicación standalone o por medio de una aplicación web (WAR) desplegada en un servidor de aplicaciones Tomcat 5.5 o 6.0.x.

En este tutorial sólo veremos la primera, así que manos a la obra. Primero, descargamos de http://apache.rediris.es/archiva/binaries/apache-archiva-1.1.1-bin.tar.gz la aplicación. Segundo, configuramos el entorno para empezar su instalación siguiendo los siguientes pasos:

  • Creamos un usuario y grupo llamados maven.
    • su -c «groupadd maven»
    • su -c «useradd -g maven maven»
    • su -c «passwd maven»
  • Creamos un directorio donde situaremos la aplicación standalone. En nuestro caso /opt/maven/archiva, cuyo propietario sera el usuario maven y grupo maven.
    • su -c «mkdir /opt/maven»
    • chown -R maven:maven /opt/maven
    • su -c «su – maven»
    • cd /opt/maven
    • mkdir archiva
    • cd archiva
    • tar -xvf apache-archiva-1.1.1-bin.tar.gz
    • mkdir repositories
    • Crear un conjunto de scripts para el arranque y la parada de archiva.

Nota

Para que archiva arranque adecuadamente el entorno de usuario debe tener configurada una jdk igual o superior a 1.5. En nuestro caso configuraremos nuestro entorno con la jdk 1.6.0_03.

  • cd /opt/maven/apache-archiva-1.1.1/bin
  • Creamos un script de arranque llamado start.sh que contiene lo siguiente.
#! /bin/bash
JAVA_HOME=/opt/jdk1.6.0_03
ARCHIVA_HOME=/opt/maven/apache-archiva-1.1.1
LOG_ARCHIVA=$ARCHIVA_HOME/logs

export JAVA_HOME

if [ ! -d $LOG_ARCHIVA ]; then
mkdir $LOG_ARCHIVA
fi

if [ -f $ARCHIVA_HOME/bin/archiva ]; then
$ARCHIVA_HOME/bin/archiva start
else
exit 1
fi

Advertencia

Es posible que al ejecutar el comando de arranque, Archiva no se inicie. Esto puede ser debido a que el script «archiva» no reconozca nuestra arquitectura y por tanto no sepa cual es el script que debe lanzar. Para solucionar este problema basta con renombrar el fichero wrapper-arquitectura por wrapper.

  • Creamos un script de parada llamado stop.sh
#! /bin/bash

JAVA_HOME=/opt/jdk1.6.0_03
ARCHIVA_HOME=/opt/maven/apache-archiva-1.1.1

LOG_ARCHIVA=$ARCHIVA_HOME/logs

export JAVA_HOME

if [ ! -d $LOG_ARCHIVA ]; then
mkdir $LOG_ARCHIVA
fi

if [ -f $ARCHIVA_HOME/bin/archiva ]; then
$ARCHIVA_HOME/bin/archiva stop
else
exit 1
fi

  • Creamos un script de inicialización (/etc/init.d/archiva), que nos permitirá iniciar archiva cuando arranque el sistema.
#!/bin/sh
#
# chkconfig: 345 60 80
# description: Arranca y para el servidor Archiva.
#
# Source function library.
. /etc/rc.d/init.d/functions

ret=0

case $1 in
start)
gprintf «Starting Archiva: «
su -c «/opt/maven/apache-archiva-1.1.1/bin/start.sh» maven &
success «Archiva startup»
ret=$?
echo
;;

stop)
gprintf «Stopping Archiva: «
su -c «/opt/maven/apache-archiva-1.1.1/bin/stop.sh» maven
ret=$?
if [ $ret = 0 ]; then
success «Archiva shutdown»
else
failure «Archiva shutdown»
fi
echo
;;
restart)
$0 stop
sleep 5
$0 start
ret=$?
;;
*)
gprintf «Usage: %s\n» «$(basename $0) {start|stop|restart}»
exit 0
;;
esac

exit $ret

  • Ahora utilizamos el comando chkconfig (similar al comando update-rc.d en sistemas basados en debian) para que cree los enlaces necesarios en rcX.d para el arranque y la parada del servicio.
  • chkconfig –add archiva
  • Si todo ha ido bien, arrancamos archiva.
  • cd /etc/init.d/
  • ./archiva start
  • Y por último, accedemos a la aplicación http://localhost:8080/archiva

3. Configuración

La primera vez que accedemos a Archiva, nos pedirá los datos para crear el usuario administrador de la aplicación:

Figura 1. Creación de usuario administrador.

pantallazo creación de usuario administrador

A continuación, deberemos logarnos en el sistema.

Figura 2. Accediendo a Archiva.

Pantallazo accediendo archiva.

Lo primero que vemos en la parte de la derecha es el menú, dividido en tres grandes bloques:

  • Find: opciones para la búsqueda de artefactos subidos a los repositorios definidos en la aplicación.
  • Manage: opciones de administración de Archiva como gestión de usuarios, informes y personalización de la aplicación.
  • Administration: opciones de gestión/administración de los repositorios.

Figura 3. Menú de navegación.

Pantallazo menú de navegación.

3.1 Search -> Find

Esta opción permite realizar búsquedas sobre los repositorios definidos. El resultado mostrado serán artefactos que coincidan con el termino buscado o aquellos artefactos que dependan de él. En esta nueva versión podremos buscar artefactos que contengan una determinada clase, método o paquete, sólo tendremos que incluir en la consulta la palabra bytecode (ejemplo: bytecode:getString).

Figura 4. Búsqueda de artefactos.

Pantallazo de búsqueda de artefactos

3.2 Search -> Find Artifact

Esta opción es muy útil en situaciones donde tenemos artefactos anónimos, sin ninguna información que permita conocer a que versión, grupo, etc… pertenece. Con esta funcionalidad podremos localizar si el artefacto en concreto se encuentra subido en algunos de los repositorios gestionados por Archiva. Esto es posible gracias a que indexa todos los recursos, generando ficheros checksum que ayudan a identificar cada artefacto unívocamente en el repositorio.

Archiva utiliza un applet de Java para generar el checksum local del artefacto que posteriormente será utilizado para localizarlo en los repositorios. Para que funcione, debemos aceptar su ejecución la primera vez que accedamos a «Find Artifact».

Figura 5. Applet de generación de checksum.

Pantallazo de applet de generación de checksum

Posteriormente adjuntamos el fichero que deseamos buscar en el repositorio y pulsamos sobre «Search». Si el artefacto se encuentra en alguno de los repositorios, Archiva nos redirigirá a él. En caso contrario nos mostrará un mensaje indicándonos que el artefacto no se ha encontrado.

Figura 6. Búsqueda de artefactos.

Pantallazo de búsqueda de artefactos

3.3 Find -> Browse

La última opción dentro del bloque «Find» es «Browse». Con esta opción podremos navegar por todos los grupos y artefactos almacenados en los repositorios.

Figura 7. Navegación por artefactos.

Pantallazo de navegación por artefactos

Al acceder al detalle de cualquier artefacto, Archiva, muestra cinco pestañas con información relativa a él: Info, Dependencies, Dependency Tree, Used by y Mailing Lists. En todas ellas, en la parte derecha, tenemos la posibilidad de descargar los recursos que se hayan subido del artefacto (source, artefact, pom.xml, etc…).

En la pestaña info, se muestra información genérica como: grupo, artefacto, versión, tipo de empaquetado y el contenido del fichero pom.xml.

Figura 8. Pestaña Info.

Pantallazo de la pestaña info

En la pestaña Dependencies se muestra la lista de artefactos de los que depende.

Figura 9. Pestaña Dependencies.

Pantallazo de la pestaña dependencies

En la pestaña Dependency Tree se muestra la misma información que en la anterior, pero presentando la jerarquía en forma de árbol.

Figura 10. Pestaña Dependency Tree.

Pantallazo de la pestaña dependency tree

En la pestaña «Used By» se muestra la lista artefactos subidos al repositorio que dependen de esta versión.

Figura 11. Pestaña Used By.

Pantallazo de la pestaña used by

Y por último la pestaña «Mailing Lists» donde podemos ver la lista de correos de los desarrolladores si estuvieran definidos en el fichero pom.xml.

Figura 12. Pestaña Mailing lists.

Pantallazo de la pestaña mailing lists

3.4 Manage -> Reports

Archiva permite generar informes sobre problemas en los artefactos almacenados en los repositorios. Los informes que podemos generar son muy limitados, únicamente nos permite filtrar por grupo y repositorio y definir el número de errores por pagina. Otro punto débil es la imposibilidad de generar informes en otro formato que no sea html.

Figura 13. Informes.

Pantallazo de informes

3.5 Manage -> User Management

Archiva gestiona el acceso a las diferentes funcionalidades y repositorios con roles, distiguiendo dos tipos: roles de administración de Archiva y roles de acceso a repositorios.

3.5.1 Roles de administración de Archiva

Nos encontramos dos roles que podemos asignar al usuario.

  • Administrador de usuarios: capaz de crear, editar y asignar permisos a otros usuarios de la aplicación.
  • Administrador de la aplicación: se puede ver como el usuario «root» en un sistema linux. Tiene completo control sobre todas las funcionalidades que archiva nos proporciona.

3.5.2 Roles de acceso a repositorios

Tenemos cuatro roles, dos de ellos que si se activan se aplican sobre todos los repositorios y otros dos que son especificos a cada repositorio.

  • Global Repository Observer: con este rol el usuario puede acceder en modo lectura a todos los repositorios y utilizar las opciones Browse y Find.
  • Global Repository Manager: el usuario puede acceder en modo lectura/escritura y administrar todos los repositorios definidos.
  • Repository Observer: mismo comportamiento del rol «Global Repository Observer», pero aplicable exclusivamente a los repositorios seleccionados por el administrador.
  • Repository Manager: mismo comportamiento del rol «Global Repository Manager» pero aplicable exclusivamente a los repositorios selecionados por el administrador.

Figura 14. Gestión de usuarios.

Pantallazo de gestión de usuarios

3.6 Manage -> Appearance

Con esta opción se permite al administrador realizar una mínima personalización de la aplicación. Podemos incluir en la parte superior derecha una imagen de la organización.

Figura 15. Personalización de aplicación.

Pantallazo de personalización de aplicación

3.7 Manage -> Upload Artifact

Esta opción realiza la misma acción que si utilizaramos el goal «deploy:deploy-file» para subir al repositorio un artefacto.

Figura 16. Subida de artefactos.

Pantallazo de subida de artefactos

3.8 Administration -> Repository Groups

Con esta nueva versión se incorpora un nuevo concepto llamado «Repositorio Virtual», que nos permitirá reunir varios repositorios definidos en la opción «Repositories», corportandose como uno único.

Figura 17. Grupo de Repositorios.

Pantallazo de grupos de repositorios

3.9 Administration -> Repositories

Con Archiva podemos configurar dos tipos de repositorios: los gestionados por el propio Archiva y los remotos. Los repositorios gestionados son locales, situados en la misma máquina donde tengamos instalado Archiva, pudiendo ser utilizados como repositorios de despligue de artefactos internos a la organización, o como almacén de artefactos de repositorios de terceros utilizando «Proxy Conectors».

Los repositorios remotos, en cambio, son aquellos donde se almacenan artefactos de terceros no gestionados por nuestro servidor y que están situados remotamente.
Los Proxies Conectors nos permiten tener en nuestras instalaciones un mirror bajo demanda de repositorios remotos, es decir, almacenamos en nuestro repositorio local todos los artefactos que sean pedidos a los repositorios remotos. Básicamente un Proxy Conector es un enlace entre un repositorio gestionado y un repositorio remoto. Indicar que Archiva nos permite asociar varios repositorios remotos a un único repositorio gestionado.

Archiva tiene configurado por defecto cuatro repositorios; dos remotos que corresponden con el repositorio central de maven y el repositorio del paquete java.net, y otros dos internos. De estos últimos recomendamos la eliminación para situarlos en otros path indenpendientes al servidor de Archiva. Para ello accedemos a la opción «Repositories» y pulsamos sobre el enlace «Delete» de los dos repositorios internos. Tras esta operación nos preguntan si deseamos eliminar la configuración del repositorio y su contenido o únicamente la configuración. En este caso, pulsaremos sobre el botón «Delete Configuration and Contents».

Figura 18. Eliminación de repositorios.

Pantallazo de eliminación de repositorios

Para añadir nuevo repositorios debemos pulsar sobre el enlace «Add» situado en la sección «Managed Repositories». Se nos pedirán una serie de datos como:

  • Identifier: representa el nombre que posteriormente utilizaremos para acceder al repositorio.
  • Name: pequeña descripción.
  • Directory: ruta donde se depositarán los artefactos.
  • Directory Index: ruta donde se deposita información necesaria de indexación de los recursos almacenados en el repositorio y necesario para poder utilizar funcionalidades como Browse, Find, etc…
  • Cron: regla donde se define cada cuanto tiempo se lanzarán los procesos de purgación del repositorio.
  • Type: con esta opción indicamos la naturaleza del repositorio, es decir, si va albergar artefactos 1.x o 2.x.
  • Repository Purge By Days Older Than: número de dias que se mantienen los artefactos Snapshots en el repositorio una vez subidos.
  • Repository Purge By Retention Count: número de artefactos Snapshot que se mantienen en el repositorio.
  • Releases Included: check que indica que el repositorio puede almacenar releases.
  • Snapshots Included: check que indica que el repositorio puede almacenar snapshots.
  • Scannable: check con el que permitimos que el repositorio pueda ser indexado para poder realizar búsqueda sobre él.
  • Delete Released Snapshots: si se encuentra activado se eliminarán los snapshots cuando se suba la release del artefacto.

Figura 19. Creación de un repositorio gestionado.

Pantallazo de creación de un repositorio gestionado

Desde la opción «Add» situada en «Remote Repositories» añadiremos repositorios remotos.

  • Identifier: identificador del repositorio.
  • Name pequeña descripción.
  • URL: dirección donde se encuentra situado el repositorio.
  • Username: nombre del usuario para acceder al repositorio privado.
  • Password: password del usuario para acceder al repositorio privado.
  • Timeout in seconds: tiempo de espera para conectarse al repositorio antes de devolver un error.
  • Type: naturaleza del tipo de artefactos almacenados en el repositorio (1.x o 2.x).

Figura 20. Creación de un repositorio remote.

Pantallazo de creación de un repositorio remote

3.10 Administration -> Proxy Connectors

Los Proxy Connectors, como hemos comentado antes, se utilizan para cachear artefactos de repositorios remotos en nuestras instalaciones, con la ventaja de reducir el tiempo de descarga a nuestro repositorio local y el tráfico que pudiera generar si todos los desarrolladores de una organización tuvieran configurado en sus ficheros settings.xml una conexión directa con los repositorios remotos.

La funcionalidad de un Proxy Connectors es supervisar las peticiones realizadas a repositorios gestionados y cachear los artefactos siguiendo una serie de políticas.
Un Proxy Connector es una asociación entre un repositorio gestionado y un repositorio remoto. Para dar de alta uno debemos pulsar sobre el botón «Add» y rellenar el formulario:

  • Network Proxy: tipo de conexión utilizada para descargar los artefactos. Puede ser una conexión directa o a través de un proxy.
  • Managed Repository: repositorio gestionado donde se depositarán los artefactos descargados del repositorio remoto.
  • Remote Repository: repositorio remoto que queremos cachear.
  • Policies: parámetros que indican el comportamiento del proxy ante el almacenamiento de los artefactos remotos.
    • Return error when: indica como se comporta Archiva cuando se produce un error en el proceso de acceso a un proxy remoto.
      • Artifact no already present: debería retornar si existe un artefacto previamente cacheado.
      • Always: siempre retorna el error.
    • Cache failures: si se produce un error en el proceso de descarga podemos decidir si se cachea o no el artefacto.
    • Releases: indica cada cuanto tiempo Archiva comprueba si hay una actualización del artefacto (never, once, hourly, dayly, always).
    • On remote error: que comportamiento se toma cuando se produce un error en uno de los repositorios remotos definidos en el proxy connector:
      • Stop: retorna el error inmediatamente.
      • Queue error: espera a recorrer todos los repositorios remotos y retorna todos los errores.
      • Ignore: descarta cualquier error.
    • Checksum: con este parámetro definimos el comportamiento cuando el checksum de los artefactos descargados es incorrecto:
      • Fail: produce un error.
      • Fix: corrige el fichero de checksum.
      • Ignore: se ignora.
    • Snapshots: mismo comportamiento que la Releases.

Además de las politicas de almacenaje, podemos añadir filtros que nos permiten decidir que grupos pueden ser o no descargados a través de ese Proxy Connector.

Figura 21. Creación de un proxy connector.

Pantallazo de creación de un proxys connector

3.11 Administration -> Legacy Support

Archiva es capaz de gestionar repositorios 1.x y 2.x. La estructura de los repositorios 1.x hace que Archiva necesite analizar el nombre de los artefactos para poder indexarlos y realizar búsquedas sobre ellos. Del análisis de los artefactos se recupera el identificador del mismo, la versión y el clasificador. En ocasiones puede que esta división sea errónea y provoque que el artefacto esté corrupto en el repositorio. Para solventar estos casos podremos definir reglas personalizadas a través de esta opción. Vamos a poner un ejemplo: imaginemos un artefacto almacenado en el path «adictos/jars/utilidades-1.0-FCS-full.jar». La división que Archiva realiza por defecto de este artefacto es:

  • Grupo/: adictos
  • Artefacto: utilidades
  • Versión: 1.0
  • Clasificador: FCS-full.

Si queremos que la Versión sea «1.0-FCS» y el clasificador «full» tendremos que dar de alta la siguiente regla:.

  • Path: adictos/jars/utilidades-1.0-FCS-full.jar
  • GroupId: adictos
  • ArtifactId: utilidades
  • Version: 1.0-FCS
  • Classifier: full
  • Type: jar

Figura 22. Creación de un mapeo de artefacto 1.x.

Pantallazo de creación de un mapeo de artefacto 1.x

3.12 Administration -> Network proxies

En una gran mayoría de organizaciones se utilizan Proxies para acceder a Internet. En estos casos, todos los Proxy Connectors definidos que necesiten conexión a Internet para acceder a los artefactos deberan ser configurados con proxy.

Figura 23. Creación de un proxy.

Pantallazo de creación de un proxy

3.13 Administration -> Repository Scanning

Desde «Repository Scanning» podremos configurar los patrones de ficheros que Archiva debe tener encuenta para considerar los ficheros como artefactos, ficheros que deben ser eliminados, ficheros que deben ser ignorados y ficheros que deben ser indexados. Además se pueden seleccionar los procesos que se ejecutarán cuando se escaneen los repositorios. Entre las tareas que podemos ejecutar se encuentra:

  • auto-remove: eliminará los ficheros que coincidan con los patrones definidos en el apartado auto-remove.
  • auto-rename: renombra posibles errores en los artefactos.
  • create-missing-checksums: crea ficheros checksum md5 y sha1 en aquellos artefactos que no tengan.
  • index-content: añade al directorio de indexación aquellos ficheros que coincidan con los patrones definidos en el apartado indexable-content.
  • metada-updater: crea o actualiza los ficheros maven-metadata.xml.
  • Repository-purge: elimina del repositorios los artefactos snapshots que no cumplan las reglas de purgación definidas en el repositorio.
  • Update-db-artifact añade los artefactos a la base de datos.
  • Validate-checksums valida los ficheros checksums contra los ficheros del repositorio.

Figura 24. Configuración tareas de escaneo.

Pantallazo de configuración tareas de escaneo

3.14 Administration -> Database

De igual forma al anterior apartado, la opción «Dababase» nos permite configurar las tareas que deben ejecutarse en los procesos de purgación de los repositorios. Entre esas tareas podemos encontrar:

  • update-db-bytecodes-stats: actualiza las estadísticas de los bytecodes de los artefactos.
  • Index-public-methods: indexa todos los metodos públicos de los artefactos.
  • Index-artefact: indexa todos los checksums de los artefactos.
  • Validate-repository-metada: comprueba los ficheros metada del repositorio con la base de datos.
  • Index-archive-toc: indexa la tabla de contenidos de archiva.
  • Update-db-project: obtiene información de los pom pertenecientes a los artefactos y los almacena en la base de datos.
  • Not-present-remove-indexed: elimina todos los contenidos indexados que no encuentre en el repositorio.
  • Not-present-remove-db-artifact: elimina los artefactos de la base de datos si no estan presentes en el repositorio.
  • Not-present-remove-db-project: elimina los proyectos de la base de datos que no se encuentren en el repositorio.

Figura 25. Configuración de tareas de base de datos.

Pantallazo de configuración de tareas de base de datos

4 RSS

Cualquier desarrollador podrá estar informado al instante de cualquier nuevo artefacto que se deposite en cualquiera de los repositorios que Archiva gestione. Para ello Archiva nos da la posibilidad de suscribirnos a dos tipos de RSS: por repositorio o por artefacto. Al primero nos suscribimos desde la opción de «Managment Repositories» y al segundo desde la opción «Browse».

5 Conclusión.

La utilización de este tipo de herramientas en organizaciones con gran número de desarrolladores, nos puede permitir reducir radicalmente el tráfico que se genera al descargar los artefactos de repositorios remotos.

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad