Gestión de las dependencias y repositorios

Si durante el desarrollo de un proyecto se ha configurado el repositorio de librerías de MADEJA como única fuente de artefactos quiere decir que a lo largo del desarrollo del proyecto se han realizado las oportunas peticiones de actualización del repositorio desde el procedimiento definido para tal propósito. Si esto es así no será necesario entregar ninguna dependencia puesto que ya estarán todas en el repositorio MADEJA.

En caso que se haya utilizado otros repositorios aparte, habrá que identificar ese conjunto de librerías que se aportan desde otros repositorios y solicitar una petición de actualización del repositorio de MADEJA tal y como indica el procedimiento.

Muchos organismos disponen de un repositorio maven propio para la recepción de sus entregas. En este caso, los proyectos deben solicitar la actualización de las librerías que necesiten al responsable del repositorio de librerías de dicho Organismo. Se recomienda a estos organismos que proporcionen un procedimiento de actualización similar al que se ha mencionado antes para el repositorio de MADEJA.

Si desde una Consejería se desea publicar una dependencia en el repositorio de MADEJA, se proporciona un mecanismo más ágil que el procedimiento definido para actualizar el repositorio.

Este método sólo aplica para aquellas dependencias creadas para la Junta de Andalucía cuyo "groupId" sea es.juntadeandalucia.[ORGANISMO]. O las que excepcionalmente la Consejería indique cumpliendo un determinado patrón de inclusión, por ejemplo "ceic/**" (Se entiende que son librerías que aún no se han adaptado a la nueva nomenclatura).

MADEJA recomienda a las distintas Consejerías crear un repositorio dedicado exclusivamente a publicar el conjunto de artefactos candidatos a ser publicados en el repositorio MADEJA. Una vez creado el repositorio, se seguirán los siguientes pasos:

1. Desde la Consejería se notificará la URL de este repositorio dedicado a los administradores del repositorio de librerías MADEJA.
2. El administrador del repositorio de librerías MADEJA creará un nuevo repositorio remoto que apunte a la URL proporcionada, y las inclusiones y exclusiones necesarias.
3. El administrador del repositorio de librerías MADEJA enlazará el nuevo repositorio remoto al repositorio ja-artifacts. De esta manera, cualquier artefacto instalado en el repositorio de la Consejería estará disponible desde el repositorio de librerías de MADEJA bajo demanda.

Las dependencias deberán también tener versionado, para que se puedan gestionar adecuadamente y poder comprobar si ya existe en el repositorio de librerías de la Consejería u Organismo o en el de MADEJA, si debe ser desplegada. Por ejemplo: spring-beans-1.2.8.jar

En todo caso, habrá que indicar el origen de la dependencia tal y como recoge la pauta "Indicar las fuentes o repositorios de las dependencias" un poco más abajo

Cabe destacar que la política de versionado de una dependencia es la suya propia, y que la que propone MADEJA está dirigida a los desarrollos hechos por y para la Junta de Andalucía.

Por ejemplo: <version>[1.1.15,1.2.0)</version>

Esta practica en fase en un entorno de desarrollo puede ser muy útil para cambiar una librería por otra con una versión compatibles, pero en una entrega para una Consejería u Organismo puede ser una complicación más a la hora de que el personal técnico pueda saber qué librerías tenía la entrega asociada en su momento. En el pom.xml de una entrega de software el proveedor debe evitar el uso de intervalos y hacer referencia a un número de versión fija.

Las dependencias que aparecen en el pom.xml de un desarrollo que usa maven tienen a su vez su propio xml, donde exponen sus dependencias con otros componentes. Si no se ha indicado el repositorio remoto (apache, jboss, etc...) del que se pueden obtener tanto la dependencia como su xml, porque la dependencia no esta pública en ningun repositorio conocido, será necesario desplegarla a mano. En este caso se debe entregar también el xml asociado a la dependencia, para que cuando se genere el paquete del software se puedan localizar las dependencias transitivas que puedan exisitir.

Toda dependencia candidata a ser instalada en el repositorio de librerías, tiene que ser "localizable" en Internet bien vía un repositorio de librerías maven que la distribuya, o bien mediante descarga desde la página web del desarrollador original de la misma. De esta manera se pretende proteger la integridad de las versiones de todos los artefactos.

Si en el desarrollo se han usado dependencias que no se encuentren en el repositorio de librerías MADEJA, habrá que solicitar una petición de actualización del repositorio indicando la "localización" de la dependencia.

Es habitual que al incluir una nueva dependencia en el fichero pom.xml, no se caiga en la cuenta de preguntarse por las dependencias transitivas que se están incluyendo. En ocasiones estas dependencias transitivas no son necesarias que se incluyan, bien porque no se hará uso de ellas en tiempo de ejecución o bien porque ya fueron incluidas explícitamente en el pom.xml o por alguna otra dependencia.

Por ello es buena práctica tener en cuenta estas dependencias transitivas y excluirlas siempre que se sepa que no son necesarias. Por ejemplo, si en un proyecto se deseará acceder a un directorio LDAP se podría hacer uso de la librería spring-ldap, sin perjucio de descargar también spring-core o spring-beans

<dependency>
    <groupId>org.springframework.ldap</groupId>
    <artifactId>spring-ldap</artifactId>     
    <version>1.2.1</version>
    <exclusions>
       <exclusion>
           <groupId>org.springframework</groupId>
           <artifactId>spring-core</artifactId>
       </exclusion>
       <exclusion>
           <groupId>org.springframework</groupId>
           <artifactId>spring-beans</artifactId>
       </exclusion>
    </exclusions>
</dependency>

El atributo scope se utiliza para limitar la "transitividad" de una dependencia, afectando de manera directa sobre el classpath utilizado para según que tarea.

Si el uso de una dependencia determinada sólo tiene sentido en las pruebas unitarias, no tiene sentido que se incluya en el war deplegable en el servidor de aplicaciones. Si para la realización de las pruebas unitarias se utiliza la librería testng y commons-httpclient se indicará de la siguiente manera:

<dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>5.7</version>
    <scope>test</scope>
    <classifier>jdk15</classifier>
</dependency>
<dependency>
    <groupId>commons-httpclient</groupId>
    <artifactId>commons-httpclient</artifactId>
    <version>3.1</version>
    <scope>test</scope>
</dependency>

Se puede obtener más información acerca de este tema en la página oficial de maven

El uso de versiones SNAPSHOT está exclusivamente orientado a entornos de desarrollo y en este contexto no tiene sentido si lo que se va a realizar es una entrega de una versión.