Cuando vayamos a desarrollar un proyecto para gvSIG 2.0 deberemos tener en cuenta varias cosas si queremos que éste tenga el respaldo oficial de gvSIG y pase a formar parte de la distribución oficial de gvSIG.

• Se usará maven como herramienta de contrucción del proyecto.

  Maven define un nombre de grupo, groupId y de identificador, artifactId, de nuestro proyecto. Se usará como groupId org.gvsig y como artifactId el groupId seguido de un identificador de nuestro proyecto.

  Por ejemplo si estamos creando un plugin para gvSIG de topografía los paquetes de nuestro proyecto comenzarán todos por org.gvsig.topography.

  El artifactId se usará para:

  • Identificar el paquete raíz de nuestro proyecto java. Todos nuestros paquetes comenzarán por el artifactId.
  • El nombre de nuestro proyecto de eclipse. Los proyectos de eclipse de nuestro desarrollo se nombrarán igual que el artifactId.
  • Los jars generados por nuestro proyecto comenzarán por el artifactId seguidos de la versión del proyecto y el clasificador de maven.

• Deberá haber una separación estricta entre API e implementación.

  Parece tema obvio, pero es muy frecuente que no exista esta separacion, y cuando existe no suele ser tan estricta como se requiere desde gvSIG.

  Los principales motivos de esto responden a temas como:

  • ¿Cómo podemos realizar valoraciones del alcance de una modificación dentro del código? ¿Cuál sería el impacto en la aplicación gvSIG si modificamos esto?

    Si tenemos definidos los APIs de forma estricta facilita enormemente el dar respuesta a esta pregunta.

  • ¿Cómo podemos documentar correctamente el uso de las librerías?. Si tenemos separada la implementación del API, es fácil centrarnos en documentar solo el API sin que se nos ande mezclando éste con la implementación.

  • ¿Cómo podemos realizar test automatizados de nuestra librería?. Si disponemos de un API claro y bien delimitado, podemos centrarnos en preparar test automatizados que comprueben las especificaciones del API de forma que podamos verificar fácilmente que un cambio en la implementación afecta o no a los consumidores del API.

• Deberá existir un sistema de test automatizados que verifiquen el funcionamiento del API de nuestro proyecto. Hasta la fecha se está usando junit para realizar estas tareas.

• Los APIs deberán estar documentados y esta documentación subida a un sitio público.

  Para la documentación de los APIs se usarán los javadocs sobre los interfaces y clases del API. La documentación del API deberá ser completa y en inglés. Para generar y desplegar éste se aprovechará la utilidad de maven para la generación de sites.

• Deberán estar identificadas las dependencias de nuestro proyecto con otras librerías.

  Esto se realizará a través de maven manteniendo actualizado ManageDependencies en el proyecto maven raíz.

• Deberá adjuntarse a nuestro proyecto un plan de pruebas. Este plan de pruebas funcionará a modo de una batería de pruebas de aceptación que el proyecto deberá pasar tras cada construcción de un instalable de gvSIG para una versión final.

• Se deberá confeccionar en ReST la documentación de usuario del proyecto. Seria deseable que esta documentación se entregase en inglés.

• Deberán desplegarse los jars de nuestro proyecto en un repositorio de maven, y seguir una política de versionado acorde a los cambios que se realicen en el proyecto. gvSIG dispone de un repositorio de maven propio en el que desplegar las librerías, pero puede utilizarse otro si se considera adecuado.

• Sería deseable la generación de una guía para el desarrollador que guiase a un desarrollador que se inicia en la utilización de las librerías del proyecto. Siempre que fuese posible esta guía debería estar en inglés.

• Si generamos un empaquetado de nuestro plugin para gvSIG deberemos cerciorarnos de que éste lleva un numero de build único.

  Debe existir una forma de identificar una distribución o empaquetado de nuestro plugin que no de lugar a dudas sobre que versión es. Para esto se le asigna un número de build a cada empaquetado de gvSIG.