Guía de la Estructura del Software

Estructura de un proyecto con múltiples módulos

En este caso el proyecto esta estructurado en módulos. Cada uno de estos a su vez es un proyecto Maven. Todos los proyectos extenderán del proyecto un proyecto padre o base.

Cada modulo se nombrará según:

<anagrama del sistema de información>-<adv. tipo de módulo>[-<sufijo>]

Módulo Base

Este es el módulo padre del proyecto, donde se describen los otros módulos que componen la aplicación.

Generalmente en un proyecto Maven con múltiples módulos representan la estructura del proyecto en la jerarquía de carpetas pero esto no es algo indispensable, pudiendo quedar el módulo padre al mismo nivel que los demás.

Estructura del Módulo Base

Definición del pom.xml:

El empaquetado Maven del módulo será pom. Este empaquetado indica que el proyecto no generará ningún entregable. El groupId será es.juntadeandalucia.consejería y el artifactId será el anagrama del sistema.

<modelVersion>4.0.0</modelVersion>
<groupId>es.juntadeandalucia.consejeria</groupId>
<artifactId>anagrama</artifactId>
<version>versión a generar</version>
<name>nombre completo del proyecto</name>
<description>Descripción libre del proyecto</description>
<packaging>pom</packaging>

Al tratarse de un proyecto base se deberán identificar todos los módulos como hijos.

<modules>
   <module>../nombre módulo</module>
   <module>../nombre módulo</module>
   ...
</modules>

Se recogerán las dependencias generales del proyecto. Se intentará que todas las dependencias sean generales, como se explicará más adelante.

<dependencies>
   <dependency>
      <groupId>groupId</groupId>
      <artifactId>artifactId</artifactId>
      <version>versión</version>
   </dependency>
   ...
</dependencies>

Se deben indicar en la entrega los repositorios usados para las dependencias. Si la Consejería posee su propio repositorio los proyectos se entregarán preparados para trabajar contra dicho repositorio. Mientras tanto sólo se podrán utilizar repositorios oficiales disponibles en Internet, y el Repositorio de Artefactos de MADEJA.

Es este módulo en el que se deben definir los perfiles para los distintos entornos y se identificará el perfil por defecto.

<profile>
   <profile>
      <id>desa</id> <!-- Perfil para el entorno de desarrollo. -->
      <properties>
         <entorno>desa</entorno> <!-- Prefijo para ficheros de filtros. -->
         <nombre propiedad>valor</nombre propiedad>  <!-- Propiedades asociadas al perfil. -->
         ...
      </properties>
   </profile>
   <profile>
      <id>pre</id> <!-- Perfil para el entorno de preproducción. -->
      <properties>
         <entorno>pre</entorno>
         <nombre propiedad>valor</nombre propiedad>
         ...
      </properties>
   </profile>
   <profile>
      <id>pro</id> <!-- Perfil para el entorno de producción. -->
      <properties>
         <entorno>desa</entorno>
         <nombre propiedad>valor</nombre propiedad>
         ...
      </properties>
   </profile>
</profiles>

<!-- Entorno por defecto. -->
<properties>
   <entorno>desa</entorno>
</properties>

Se definirán los aspectos generales a utilizar y que afectan a todo el proyecto.

<build>
   <!-- Fichero de filtros a utilizar. -->
   <filters>
      <!-- Se utiliza el fichero de configuración del proyecto base. -->
      <filter>../<anagrama>/src/main/filters/env-${entorno}.properties</filter>
   </filters>
   <!-- Recursos a incluir en el entregable e indicación de si se filtrarán. -->
   <resources>
      <!-- Recursos de tipo imágenes, plantillas... que no forman parte de la configuración. -->
      <resource>
         <directory>src/main/resources</directory>
         <filtering>false</filtering>
      </resource>
      <!-- Recursos de configuración como properties -->
      <resource>
         <directory>src/main/config</directory>
         <filtering>true</filtering>
      </resource>
   </resources>
   <!-- Propiedades de los plugin utilizados. -->
   <plugins>
      <!-- Propiedades de compilación. -->
      <plugin>
         <artifactId>maven-compiler-plugin</artifactId>
         <configuration>
            <source>versión java de los fuentes</source>   <!-- 1.4 o 1.5 -->
            <target>versión java de los bytecodes</target> <!-- 1.4 o 1.5 -->
         </configuration>
      </plugin>
   </plugins>
</build>

Finalmente se definirán los informes a generar en el sitio de documentación del proyecto.

<reporting>
   <plugins>
      <!-- Documentación Javadoc. -->
      <plugin>
         <artifactId>maven-javadoc-plugin</artifactId>
         <configuration>
            <aggregate>true</aggregate>
            <minmemory>128m</minmemory>
            <maxmemory>512</maxmemory>
            <breakiterator>true</breakiterator>
            <quiet>true</quiet>
            <verbose>false</verbose>
            <source>1.5</source>
            <linksource>true</linksource>
            <links>
               <!-- JSE -->
               <link>http://java.sun.com/j2se/1.5.0/docs/api/</link>
               <link>http://java.sun.com/j2se/1.4.2/docs/api/</link>
               <link>http://java.sun.com/j2se/1.3/docs/api/</link>

               <!-- JEE -->
               <link>http://java.sun.com/j2ee/1.4/docs/api/</link>
               <link>http://java.sun.com/j2ee/sdk_1.3/techdocs/api/</link>

               <!-- Libraries -->
               <link>url de documentación api de librerías<link>
               ...
            </links>
         </configuration>
      </plugin>
      <!-- Código fuente. -->
      <plugin>
         <artifactId>maven-jxr-plugin</artifactId>
         <configuration>
            <aggregate>true</aggregate>
         </configuration>
      </plugin>
   </plugins>
</reporting>

Módulo Librería

Estos módulos son componentes generados para el proyecto, que pueden ser empaquetados por separado para su reutilización más adelante en otros proyectos. Es frecuente encontrar varios en un mismo sistema, por lo que se utilizará el sufijo para distinguirlos. Un caso particular de este sería el módulo Su nombre será, por tanto:

anagrama-lib-sufijo

Estructura del Módulo

El módulo albergará los fuente Java de la librería, los recursos a incluir en ella y los ficheros de configuración. Dichos ficheros utilizarán parámetros y las posibilidades de filtrado con Maven para la configuración por entorno.

Definición del pom.xml

Ya que el entregable será un paquete jar se utilizará el empaquetado jar.

El groupId será es.juntadeandalucia.consejeria y el artifactId será el anagrama del sistema-lib-sufijo. En este módulo y en todos los siguientes ha que indicar con el elemento que este módulo extiende a otro que es el base.

<!-- Datos básicos del proyecto. -->
<modelVersion>4.0.0</modelVersion>
<parent>
   <groupId>es.juntadeandalucia.consejeria</groupId>
   <artifactId>anagrama</artifactId>
   <version>versión del módulo base</version>
   <relativePath>../anagrama/pom.xml</relativePath>
</parent>
<groupId>es.juntadeandalucia.consejeria</groupId>
<artifactId>anagrama-lib-sufijo</artifactId>
<version>versión a generar</version>
<name>Módulo de la librería nombre de la librería de nombre completo del proyecto</name>
<description>Descripción libre del proyecto</description>
<packaging>jar</packaging>

Módulo de Persistencia

Este módulo es el encargado de recoger los fuentes, recursos y ficheros de configuración. Dichos ficheros utilizarán parámetros y las posibilidades de filtrado con Maven para la configuración por entorno. El nombre del módulo sería:

anagrama-per

Estructura del Módulo

Definición del pom.xml

Ya que el entregable será un paquete jar se utilizará el empaquetado jar.

<!-- Datos básicos del proyecto. -->
<modelVersion>4.0.0</modelVersion>
<parent>
   <groupId>es.juntadeandalucia.consejeria</groupId>
   <artifactId>anagrama</artifactId>
   <version>versión del módulo base</version>
   <relativePath>../anagrama/pom.xml</relativePath>
</parent>
<groupId>es.juntadeandalucia.consejeria</groupId>
<artifactId>anagrama-per</artifactId>
<version>versión a generar</version>
<name>Módulo de persistencia</name>
<description>Descripción libre del proyecto</description>
<packaging>jar</packaging>

Módulo de Negocio

Para abstraernos del framework que se use para la capa de negocio, llamaremos a estos módulos "neg", aúnque este no es un tipo de empaquetamiento, para empaquetar por ejemplo un módulo con la lógica de negocio en EJB habría que especificar el empaquetamiento ejb en maven, si usamos cualquier otro framework para la capa de negocio como Spring se podría usar un empaquetamiento jar.

En este módulo se agrupará la lógica de negocio. Si se encuentran varios módulos de negocio en un mismo sistema se utilizará el sufijo para diferenciarlos. El nombre será, por tanto:

anagrama-neg

Estructura del Módulo

Definición del pom.xml

En el caso en que este módulo sea un paquete de EJBs se utilizará el empaquetado ejb maven y seguramente se use otro modulo heredando del mismo modulo base para el empaquetamiento ear.

En otros casos en que la lógica de negocio no se base en EJB el empaquetado puede ser simplemente un jar o una parte que se añada a un war final.

El groupId será es.juntadeandalucia.consejeria y el artifactId será el anagrama del sistema-neg-. Se indicará que el módulo extiende al base.

<!-- Datos básicos del proyecto. -->

El módulo albergará el código fuente, sus recursos y los recursos de configuración.
<modelVersion>4.0.0</modelVersion>
<parent>
   <groupId>es.juntadeandalucia.consejeria</groupId>
   <artifactId>anagrama</artifactId>
   <version>versión del módulo base</version>
   <relativePath>../anagrama/pom.xml</relativePath>
</parent>
<groupId>es.juntadeandalucia.consejeria</groupId>
<artifactId>anagrama-neg</artifactId>
<version>versión a generar</version>
<name>Módulo de Negocio</name>
<description>Descripción libre del proyecto</description>
<packaging>ejb</packaging> <!-- si estamos usando EJBs -->

Las dependencias con librerías de terceros se deben modelar como dependencias generales y definirlas en el módulo base. Pero las dependencias internas si deben describirse. Estas dependencias se refieren a los otros módulos del sistema de los que depende el web.

<!-- Dependencias internas. -->
<dependencies>
   <dependency>
      <groupId>es.juntadeandalucia.consejeria</groupId>
      <artifactId>anagrama-tipo[-sufijo]</artifactId>
      <version>versión de la que depende</version>
      <type>empaquetado del módulo</type>
   </dependency>
   ...
</dependencies>

Si se quiere utilizar el modelo de ejbs de la versión 3.0 se debe indicar expresamente.

<build>
   <plugins>
      <plugin>
         <artifactId>maven-ejb-plugin</artifactId>
         <configuration>
            <ejbVersion>3.0</ejbVersion>
         </configuration>
      </plugin>
   </plugins>
</build>

Módulo Web

Los módulos web generan como entregable un paquete war, por lo que su empaquetado será war.

Estructura del Módulo

El módulo albergará los fuente Java de la aplicación, los recursos a incluir en ella, los ficheros de configuración y los recursos web. Los ficheros de configuración utilizarán parámetros con las capacidades de filtrado de Maven para la configuración por entorno. El nombre será, por tanto:

anagrama-web

El uso de sufijos es opcional pues es bastante frecuente que un sistema tenga un único módulo web.

Definición del pom.xml

Ya que el entregable será un paquete war se utilizará el empaquetado war. El groupId será es.juntadeandalucia.consejeria y el artifactId será el anagrama del sistema-web-. Se indicará que el módulo extiende al base.

<!-- Datos básicos del proyecto. -->
<modelVersion>4.0.0</modelVersion>
<parent>
   <groupId>es.juntadeandalucia.consejeria</groupId>
   <artifactId>anagrama</artifactId>
   <version>versión del módulo base</version>
   <relativePath>../anagrama/pom.xml</relativePath>
</parent>
<groupId>es.juntadeandalucia.consejeria</groupId>
<artifactId>anagrama-web[-sufijo]</artifactId>
<version>versión a generar</version>
<name>Módulo de la librería nombre de la librería de nombre completo del proyecto</name>
<description>Descripción libre del proyecto</description>
<packaging>war</packaging>

Las dependencias con librerías de terceros se deben modelar como dependencias generales y definirlas en el módulo base. Pero las dependencias internas si deben describirse. Estas dependencias se refieren a los otros módulos del sistema de los que depende el web.

<!-- Dependencias internas. -->
<dependencies>
   <dependency>
      <groupId>es.juntadeandalucia.consejeria</groupId>
      <artifactId>anagrama-tipo[-sufijo]</artifactId>
      <version>versión de la que depende</version>
      <type>empaquetado del módulo</type>
   </dependency>
   ...
</dependencies>

Por defecto Maven empaqueta las dependencias del módulo en el fichero war de salida. Cuando el módulo se vaya a encapsular dentro de una aplicación JEE se indicará a Maven que no incluya las librerías en el war sino que las utilice directamente de la aplicación JEE.

<!-- Exclusión de dependencias del paquete war. -->
<build>
   <plugins>
      <plugin>
         <artifactId>maven-war-plugin</artifactId>
         <configuration>
            <warSourceExcludes>WEB-INF/lib/*.jar</warSourceExcludes>
            <archive>
               <manifest>
                  <addClasspath>true</addClasspath>
                  <classpathPrefix>lib/</classpathPrefix>
               </manifest>
            </archive>
         </configuration>
      </plugin>
   </plugins>
</build>

Es frecuente que dentro de los recursos web, sobretodo en la carpeta de configuración WEB-INF, se utilicen parámetros que cambien por entorno. Si se da esta circunstancia será necesario indicar las carpetas que se quieren filtrar (ademas de src/main/config que ya está identificada en el módulo base). Ya que estas carpetas no van en el directorio de clases sino en el raíz del war, deben configurarse en el plugin correspondiente.

<!-- Propiedades generales. -->
<build>
   <plugins>
      <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-war-plugin</artifactId>
         <configuration>
            <webResources>
               <resource>
                  <directory>src/main/webapp</directory>
                  <filtering>true</filtering>
               </resource>
            </webResources>
         </configuration>
      </plugin>
   </plugins>
</build>

Módulo de Web Service

Los módulos de servicios web generan como entregable un paquete war, por lo que su empaquetado será war. Su tipo en cambios será ws para indicar claramente que se trata de un Web Service. Se utilizarán sufijos para identificar cada uno de los Web Service del sistema. El nombre será, por tanto:

anagrama-ws-sufijo

Definición del pom.xml

Ya que el entregable será un paquete war se utilizará el empaquetado war. El groupId será es.juntadeandalucia.consejeria y el artifactId será el anagrama del sistema-ws-. Se indicará que el módulo extiende al base.

<!-- Datos básicos del proyecto. -->
<modelVersion>4.0.0</modelVersion>
<parent>
   <groupId>es.juntadeandalucia.consejeria</groupId>
   <artifactId>anagrama</artifactId>
   <version>versión del módulo base</version>
   <relativePath>../anagrama/pom.xml</relativePath>
</parent>
<groupId>es.juntadeandalucia.consejeria</groupId>
<artifactId>anagrama-ws-sufijo</artifactId>
<version>versión a generar</version>
<name>Módulo del servicio web nombre de nombre completo del proyecto</name>
<description>Descripción libre del proyecto</description>
<packaging>war</packaging>

Las dependencias con librerías de terceros se deben modelar como dependencias generales y definirlas en el módulo base. Pero las dependencias internas si deben describirse. Estas dependencias se refieren a los otros módulos del sistema de los que depende el web service.

<!-- Dependencias internas. -->
<dependencies>
   <dependency>
      <groupId>es.juntadeandalucia.consejeria</groupId>
      <artifactId>anagrama-tipo[-sufijo]</artifactId>
      <version>versión de la que depende</version>
      <type>empaquetado del módulo</type>
   </dependency>
   ...
</dependencies>

Por defecto Maven empaqueta las dependencias del módulo en el fichero war de salida. Cuando el módulo se vaya a encapsular dentro de una aplicación JEE se indicará a Maven que no incluya las librerías en el war sino que las utilice directamente de la aplicación JEE.

<!-- Exclusión de dependencias del paquete war. -->
<build>
   <plugins>
      <plugin>
         <artifactId>maven-war-plugin</artifactId>
         <configuration>
            <warSourceExcludes>WEB-INF/lib/*.jar</warSourceExcludes>
            <archive>
               <manifest>
                  <addClasspath>true</addClasspath>
                  <classpathPrefix>lib/</classpathPrefix>
               </manifest>
            </archive>
         </configuration>
      </plugin>
   </plugins>
</build>

Es frecuente que dentro de los recursos web, sobretodo en la carpeta de configuración WEB-INF, se utilicen parámetros que cambien por entorno. Si se da esta circunstancia será necesario indicar las carpetas que se quieren filtrar (ademas de src/main/config que ya está identificada en el módulo base).

<!-- Propiedades generales. -->
<build>
   <!-- Recursos a incluir en el entregable e indicación de si se filtrarán. -->
   <resources>
      <!-- Recursos web que se quiere filtrar. -->
      <resource>
         <targetPath>webapp</targetPath>
         <directory>src/main/webapp</directory>
         <filtering>true</filtering>
      </resource>
   </resources>
</build>

Módulo Enterprise

El tipo de módulo será ear, pues el módulo generará un entregable de dicho tipo. Casi nunca existen varias aplicaciones JEE en un mismo sistema, por lo que el sufijo no se utilizara por lo general. El nombre será, por tanto:

anagrama-ear

Por lo general el módulo ear no tiene ningún elemento propio. Ya que los módulos y librerías que incluirá se definen como dependencias.

Estructura del Módulo

Definición del pom.xml

Ya que el entregable será una aplicación JEE se utilizará el empaquetado ear. El groupId será es.juntadeandalucia.consejeria y el artifactId será el anagrama del sistema-ear.

Se indicará que el módulo extiende al base.

<!-- Datos básicos del proyecto. -->
<modelVersion>4.0.0</modelVersion>
<parent>
   <groupId>es.juntadeandalucia.consejeria</groupId>
   <artifactId>anagrama</artifactId>
   <version>versión del módulo base</version>
   <relativePath>../anagrama/pom.xml</relativePath>
</parent>
<groupId>es.juntadeandalucia.consejeria</groupId>
<artifactId>anagrama-ear</artifactId>
<version>versión a generar</version>
<name>Aplicación JEE de nombre completo del proyecto</name>
<description>Descripción libre del proyecto</description>
<packaging>ear</packaging>

Se indicarán como dependencias internas los módulos que deben incluirse en el ear. Que por lo general serán todos.

<!-- Dependencias internas. -->
<dependencies>
   <dependency>
      <groupId>es.juntadeandalucia.consejeria</groupId>
      <artifactId>anagrama-tipo[-sufijo]</artifactId>
      <version>versión de la que depende</version>
      <type>empaquetado del módulo</type>
   </dependency>
   ...
</dependencies>

Para la generación del application.xml deberá describirse la aplicación.

<!-- Propiedades de la aplicación JEE. -->
<build>
   <plugins>
      <plugin>
         <artifactId>maven-ear-plugin</artifactId>
         <configuration>
            <displayName>
               Nombre a mostrar en el servidor de aplicaicones
            </displayName>
            <description>
               Descripción a mostrar en el servidor de aplicaciones.
            </description>
            <modules>
               <!-- Para módulos y servicios web. -->
               <webModule>
                  <groupId>es.juntadeandalucia.consejeria</groupId>
                  <artifactId>anagrama-web-sufijo</artifactId>
                  <!-- El contexto de publicación puede depender del entorno. -->
                  <contextRoot>%{url-aplicacion}</contextRoot>
                  <bundleFileName>anagrama-web-${version}.war</bundleFileName>
               </webModule>
               <!-- Para módulos de ejb. -->
               <ejbModule>
                  <groupId>es.juntadeandalucia.consejeria</groupId>
                  <artifactId>anagrama-web-sufijo</artifactId>
                  <bundleFileName>anagrama-neg-${version}.jar</bundleFileName>
               </ejbModule>
            </modules>
         </configuration>
      </plugin>
   </plugins>
</build>

Módulo de Aplicación de Escritorio

Estos módulos son de tipo dsk y pueden encontrarse varios en un mismo sistema, por lo que se utilizará el sufijo para distinguirlos. Su nombre será, por tanto:

<anagrama>-dsk-<sufijo>

Estructura del Módulo

Definición del pom.xml

Ya que el entregable será un paquete jar se utilizará el empaquetado jar. El groupId será es.juntadeandalucia.consejeria y el artifactId será el anagrama del sistema-dsk-. Se indicará que el módulo extiende al base.

<!-- Datos básicos del proyecto. -->
<modelVersion>4.0.0</modelVersion>
<parent>
   <groupId>es.juntadeandalucia.consejeria</groupId>
   <artifactId>anagrama</artifactId>
   <version>versión del módulo base</version>
   <relativePath>../anagrama/pom.xml</relativePath>
</parent>
<groupId>es.juntadeandalucia.consejeria</groupId>
<artifactId>anagrama-lib-sufijo</artifactId>
<version>versión a generar</version>
<name>Módulo de escritorio nombre de nombre completo del proyecto</name>
<description>Descripción libre del proyecto</description>
<packaging>jar</packaging>

Estructura de un proyecto web simple

En algunos casos el proyecto puede no tener una estructura tan compleja que requiera de una separación en módulos (aunque si en capas dentro del proyecto lógicamente). Para estos casos la estructura del proyecto web simple es la siguiente:

En el punto siguiente podemos ver como crear un proyecto con esta estructura desde maven.

Archetype Maven para la estructura simple

Para crear un proyecto con la estructura simple con JSF, Facelets, Spring, JPA con Hibernate usaremos un archetype que previamente hemos generado con el comando mvn archetype:create-from-project.

Par ejecutar el archetype seguiremos los siguientes pasos:

• Descargamos el archtype de MADEJA para la estructura simple del enlace archetype.zip y lo descomprimimos

• Lo instalamos en nuestro repositorio local

  mvn install

• Ejecutamos plugin archetype

  mvn archetype:generate -DarchetypeCatalog=Local

Y rellenamos los datos de nuestro proyecto.

• Para ver la aplicación resultante ejecutamos el siguiente goal de maven:

  mvn jetty:run

• y nos vamos al navegador en http://localhost:8080
  

La aplicación resultante de este archetype también esta disponible para descargar directamente en este enlace bibliotecasrc.zip

La estructura del proyecto la podemos ver en la imagen siguiente. Además este proyecto viene ya publicado bajo la licencia EUPL.

Descripción de Repositorios

Como ya se ha dicho existe ya un repositorio común de librerías par la Junta de Andalucía. Ahora mismo esta basado en la herramienta Artifactory.

Para configurar el repositorio de librerías de la Junta de Andalucía, hay que añadir un par de cosas a nuestros proyectos, en el pom.xml. Las lineas con los datos de nuestro repositorio de dependencias actual en producción:

<repositories>
    <repository>
        <releases ></releases>
    <snapshots />
          <id>CatalogoInterno</id>
          <name>CatalogoInterno</name>
    <url>http://srvrepositorio.junta-andalucia.es/repository/</url>
    </repository>   
</repositories>

En el caso de que el Organismos o Consejería disponga de un repositorio de librerías propio se debe configurar para que pueda leer del repositorio central y se pondrá en el pom.xml del proyecto antes que el central. De esta manera cuando maven le pida una librería y no la encuentre en el repositorio de la Consejería pero si el central, este se lo pasara y se la quedara ya cacheada para el futuro.

<repositories>
    <repository>
          <id>RepositorioLibreríasDeLaConsejería</id>
          <name>RepositorioLibreríasDeLaConsejería</name>
    <url>[URL Artifactory Consejería/Organismo]</url>
    </repository> 
    <repository>
        <id>CatalogoInterno</id>
          <name>CatalogoInterno</name>
    <url>http://srvrepositorio.junta-andalucia.es/repository/</url>
    </repository> 
</repositories>

Como se indica en la Directriz de Gestión de las Dependencias y Repositorios, es el proveedor del código fuente el que debe añadir estos repositorios a los pom.xml del proyecto antes de la entrega.

Para que el artifactory de la Consejería pueda descargar dependencias del central de la Junta de Andalucía se debe añadir a $ARTIFACTORY_HOME/etc/artifactory.config.xml las siguientes lineas:

<remoteRepository>
            <remoteRepository>
            <key>CentralJunta</key>
            <handleReleases>true</handleReleases>
            <handleSnapshots>false</handleSnapshots>
            <excludesPattern>org/artifactory/**,org/jfrog/**</excludesPattern>
            <url>http://srvrepositorio.junta-andalucia.es/repository/</url>
</remoteRepository>

Para que además de las dependencias propias del software, maven pueda descargar plugins de los repositorios remotos hay que añadir ciertas lineas al pom.xml.

<pluginRepositories> 
    <pluginRepository>
             <id>RepositorioLibreríasDeLaConsejería</id>
              <name>RepositorioLibreríasDeLaConsejería</name>
              <url>[URL Artifactory Consejería/Organismo]</url>
    </pluginRepository> 
    <pluginRepository>
              <id>CatalogoInterno</id>
              <name>CatalogoInterno</name>
              <url>http://srvrepositorio.junta-andalucia.es/repository/</url>
    </pluginRepository> 
</pluginRepositories>

Opcionalmente la empresa puede utilizar desde sus propias instalaciones y poner el el pom.xml en tercer lugar el repositorio externo de la Junta de Andalucía.

<repositories>
    <repository>
          <id>RepositorioLibreríasDeLaConsejería</id>
          <name>RepositorioLibreríasDeLaConsejería</name>
    <url>[URL Artifactory Consejería/Organismo]</url>
    </repository> 
    <repository>
        <id>CatalogoInterno</id>
          <name>CatalogoInterno</name>
    <url>http://srvrepositorio.junta-andalucia.es/repository/</url>
    </repository> 
    <repository>
        <id>RepositorioExterno</id>
          <name>RepositorioExterno</name>
    <url>http://www.juntadeandalucia.es/repositorio/repository/</url>
    </repository> 
</repositories>

Descripción de las Dependencias

No se deben admitir entregas con dependencias con un groupId inventado del tipo :

<dependency>
    <groupId>lib</groupId>
    <artifactId>.....
</dependency>

"o"

<dependency>
    <groupId>nombreProye</groupId>
    <artifactId>.....
</dependency>

Ver también la Directriz de Gestión de las Dependencias y Repositorios.

Configuración del plugin SCM de Maven

La configuración del plugin SCM de maven nos puede servir para automatizar alguna tarea con nuestro sistema de control de versiones.

Además es un requisito obligatorio si subimos un pom.xml de un proyecto a la aplicación web del Catalogo de Software de la Junta, ya que usa la configuración de las etiquetas del pom.xml para descargarse los fuentes del SCM y una crear nueva versión descargable desde la aplicación.

Así pues para subir el pom.xml de un nuevo desarrollo que se da de alta en la aplicación o de una nueva versión debemos tener definido en el pom.xml la configuración del sistema de control de versiones, en principio puede ser cualquiera de los que el plugin scm de Maven soporta (Bazaar, CVS, Mercurial, Perforce, StarTeam, Subversion, CM Synergy). En este aspecto todas las pruebas se han hecho con Subversión.

Para que el proceso batch que hace el checkout del proyecto funcione correctamente es necesario que exista visibilidad de la máquina donde este el subversión desde la máquina de la aplicación del Catálogo de Software de la Junta. En principio subversión puede trabajar con el puerto 3690 si usamos svnserve, o si usamos el módulo para publicarlo con Apache2 por los puertos 80 (si es http) o 443 (si es https).

Ej: Para configurar el plugin scm apuntando a una primera versión estable de un proyecto “proyectoDeEjemplo” y queremos que el pom.xml se suba al Catalogo de Software para que este cree la nueva versión indicaríamos lo siguiente:

<scm>
    <connection>
        scm:svn:https://subversion/proyectoDeEjemplo/tags/1.0.0/
    </connection>
</scm>

Si el Organismo o Consejería tienen un sistema de control de versiones, cuando se quiera subir los fuentes de una nueva versión al Catálogo de software bastara con subir el pom.xml con la configuración apuntando al nuevo tag.

El proveedor debe añadir la configuración del plugin scm con los datos del sistema de control de versiones de entrega de la Consejería u Organismo apuntando al tag o branch concreto de la entrega.