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.