:Version: 1.12


Alcance 
========

Este documento cubre los requerimientos que debe
cumplir un desarrollo para pasar a ser un *proyecto
oficial de gvSIG*. 


Exclusiones
===============

Este documento no cubre:

- Qué debe cumplir un proyecto para que se incluya en la
  *distribución oficial de la aplicación gvSIG*.

  Para que se incluya en la distribución oficial de gvSIG deberá 
  ser un *proyecto oficial gvSIG*, pero que cumpla este requerimiento 
  no lo garantiza de forma automática. 

- Modificaciones o contribuciones a código ya existente en gvSIG.

  Si desea aportar código a un proyecto ya existente en gvSIG consulte
  el documento `Contribuciones y parches al código de gvSIG`_.


Niveles de oficialidad de contribuciones de desarrollo en gvSIG
==================================================================

Antes de ver estos requerimientos, hay que concretar que existen dos niveles de
oficialidad que puede tener un desarrollo:

* **Nivel básico**. Se integra el testeo, documentación de usuario pero *el proyecto
  gvSIG* no se hace cargo de mantenerlo, corrección de bugs, añadir nuevas
  funcionalidades o adaptarlo a una nueva versión.

  Si se decide incluir en una distribución oficial y para una nueva versión 
  no compila o falla en tiempo de ejecución o hace que
  otra extensión falle, simplemente se comunicará al contribuidor que aporta la
  extensión y si no dedica recursos a ello **se retirará de la versión**.

  Este nivel apenas cubre restricciones de empaquetado, documentación, y testing
  de usuario, no exigiendo que se cumplan ninguna de las normas o
  recomendaciones respecto a diseño e implementación, con lo que mantener el
  desarrollo para los miembros que estén trabajando con gvSIG puede tener un
  coste bastante elevado.

* **Nivel completo**. La contribución se integra tanto a nivel de testeo y
  documentación de usuario como de desarrollo. El proyecto gvSIG podrá hacerse
  cargo de la corrección de algún bug y la adaptación a las nuevas versiones que
  vayan surgiendo, todo ello en función de los recursos que tenga el *proyecto*
  en ese momento.

La principal diferencia de un nivel a otro estriba en que el uno fija requerimientos relacionados
con el empaquetado y distribución de un proyecto, mientras que el otro entra ya en temas 
relacionados con el desarrollo (análisis, diseño, codificación, documentación
para desarrolladores,...)

Requerimientos para un desarrollo oficial de gvSIG
=============================================================

Los requerimientos que fija cada nivel deben interpretarse como acumulativos,
siempre que no se diga lo contrario en lo que a algún requerimiento se refiere.
Esto quiere decir que para estar en el *nivel completo* debe cumplir los del *nivel
básico*.

De los requerimientos a cubrir por un proyecto para pasar a ser un proyecto
oficial de gvSIG, algunos deberán cubrirse al inicio del proceso de validación o
certificación mientras que otros podrán irse cubriendo a lo largo del proceso.


Nivel básico
--------------

Requerimientos al inicio del proceso de certificación:

* Deberá suministrarse una persona de contacto con capacidad para
  toma de decisiones en todo lo referente al desarrollo.

* La licencia del desarrollo debe ser compatible `GPL v2`_ o posterior 
  y no debe usar ninguna otra
  librería que sea incompatible con esta licencia.

  En cuanto a la documentación entregada junto con el proyecto para conseguir
  el reconocimiento de proyecto oficial, deberá usarse una licencia 
  compatible `GPL v2`_ o posterior o una licencia `Creative Commons`_ que
  permita el uso comercial de esta asi como su modificación manteniendo
  las mismas restricciones de redistribución que la documentación
  original.
  
* Deberá entregarse un informe de dependencias de la librería o extensión, en el
  que se indique de qué librerías depende y su versión. Este informe debe
  contemplar las dependencias con otras extensiones y librerías de gvSIG,
  estando estas dependencias bien identificadas.

  Así mismo también se indicarán las dependencias con librerías nativas.

  Este documento deberá mantenerse actualizado a lo largo de la vida del
  proyecto.

  Si el proyecto usa maven como mecanismo de construcción bastará con 
  entregar el informe de *dependencias* del sitio maven generado con 
  *mvn site*. En caso de no usar maven se utilizará la plantilla 
  `Project Dependencies`_.

* Deberá existir una forma inequívoca de identificar una revisión del 
  desarrollo. Normalmente si es una librería deberá llevar un número de versión
  en el nombre del *jar*, y si es una extensión un número de *build* único para
  esa extensión. No deberán existir dos binarios distintos con el mismo nombre y
  número de versión.

* Los fuentes a partir de los que se generen los binarios y las herramientas 
  necesarias para generarlos deberán estar de acceso
  público

  Actualmente gvSIG está usando la forja de OSOR_ como espacio para el proyecto
  en el que se incluye un repositorio de SVN de acceso público en modo lectura,
  *trackers* para errores y tareas, etc. Si el proyecto no dispone de
  infraestructura para su gestión, gvSIG puede coordinar la creación de un nuevo
  proyecto para el colaborador.

* Cuando se descarguen los fuentes desde el repositorio de fuentes deberá
  existir en el raíz del proyecto un fichero `README.txt`_ que describa qué hay
  que hacer para compilar, desplegar y generar el instalable.

Los requerimientos a cubrir a lo largo del proceso de certificación son:

* Deberá existir una `documentación de análisis`_ que describa
  el desarrollo.

  No es preciso llegar a nivel de diseño, pero sí es imprescindible
  que esté a nivel de análisis. Grandes módulos y relación de estos
  con otros módulos de gvSIG.

* Deberá suministrarse una forma repetible y documentada de **generar
  instalables** para la extensión en gvSIG. Se preferirá que se use
  el procedimiento al uso para la versión corriente de gvSIG para
  empaquetar las extensiones.

* Deberá ser internacionalizable usando las librerías de gvSIG para
  ello. Se entregará como mínimo en **inglés**.

* Deberá de entregarse un manual de usuario, en formato ReST y según   
  las normas de redacción de documentación vigentes en 
  gvSIG (`Guía para documentar`_). La documentación de usuarios a
  entregar deberá cubrir:
  
  - Documentación de uso.
  - Documentación de instalación.
  - Créditos que deben incluirse en el manual de gvSIG cuando
    se incluya la documentación asociada a este proyecto.

* Debera suministrarse un instalable del proyecto. 

  Si es un plugin para gvSIG 
  se recomienda usar las reglas de nombrado para este o en su lugar
  suministrar unas claras que seran evaluadas por el equipo de gvSIG.
  
  Este instalable se encargara de instalar la extension sobre un gvSIG, y debera
  suministrar un fichero con los metadatos del plugin siguiendo el formato
  inficado en la plantilla para estos (`package.info (Template)`_).

* En lo que a **testing** se refiere los requerimientos serian:

  1. Deberá diseñarse un Plan de Pruebas (PDP) que cubra por entero las nuevas funcionalidades, como mínimo hasta el nivel de caso de prueba. Se tendrán en cuenta tanto las pruebas funcionales como las de persistencia. El PDP se introducirá en la aplicación de gestión de Planes de Prueba del proyecto y se realizará una primera ejecución desde la misma. Podrá solicitarse también la ejecución de una campaña de pruebas, que el Área de Testing diseñará ex-profeso, en función del análisis del impacto de los nuevos desarrollos sobre el resto de la aplicación, incluyendo pruebas de regresión y de persistencia. Recomendablemente se dará de alta un boletín de bug por cada error encontrado al ejecutar las pruebas, indicando el paso concreto en el que se ha detectado el error.

  2. Se abordará una fase de estabilización en la que un equipo de desarrolladores y otro de *testers* trabajarán de manera intensiva y coordinada en la corrección de errores, tanto en los propios de las nuevas funcionalidades como en los que haya provocado la integración de éstas en el resto de la aplicación.
  
  3. Cuando para una versión de gvSIG el desarrollo no pase el plan de pruebas este perderá la denominación de proyecto oficial para esa versión de gvSIG.
  
  4. Deberá existir un gestor de bugs y nuevas funcionalidades de acceso publico, permitiendo a usuarios anónimos que puedan dar de alta tickets en él.
     
     En caso de que no se disponga de uno se podría usar la forma de OSOR, para albergar los fuentes, descargas de binarios y gestión de tickets para ese proyecto, y en última
     instancia se podrían incluir en el gestor de bugs de la aplicación gvSIG.

  `Ver esquema general de procedimientos de testing`_

* Deberá haber un plugin de gvSIG por funcionalidad o grupo de funcionalidades
  relacionadas desde el punto de vista del usuario, habiendo un proyecto
  de eclipse para cada uno de los plugins. 

* Deberá existir una política clara y conocida en relación al mantenimiento
  del número de versión del proyecto. 

* Deberá existir una política clara y conocida en relación al nombrado
  de los ficheros de la distribución del proyecto.

* La instalación de un plugin en gvSIG no deberá sobre escribir ninguna de las
  librerías que se incluyan con la distribución oficial de gvSIG.

Existen dos plantillas en formato ReST_ que deberán ser rellenadas y 
entregadas con los datos básicos del proyecto, la `ficha del proyecto`_
y los `contactos del proyecto`_.


Nivel completo
----------------

Este nivel sólo aporta requerimientos a cubrir al final del proceso
de certificación.

* Se utilizara maven_ como entorno de construcción de la
  extensión o librería, utilizando la estructura
  de proyecto para gvSIG. Con los criterios de nombrado de
  paquetes, artefactos y librerías de gvSIG.
  
  Asi mismo deberan estar correctamente cumplimentados los ficheros
  *pom.xml* incluyendo por ejemplo:
  
  * Descripción del proyecto.
  * Enlaces a repositorio de código.
  * Enlaces a listas de correo.
  * Desarrolladores.
  * Etc.


* Existirá una documentación completa del API a través
  de los *javadocs*, y un mecanismo que permita desplegarlos
  en el sitio donde residan éstos en el proyecto gvSIG.
  La documentación del API se redactará en **inglés**.

* Deberán existir pruebas automatizadas,
  usando tests JUnit_ que cubran el API de la extensión o librería.
  
* Habrá una separación estricta entre la lógica y la parte de 
  *interface* de usuario.

* Habrá una separación estricta entre API e implementación,
  generándose una librería para el API separada de la implementación.
  Tanto para la **lógica** como para el **interface de usuario**.

* Deberá seguir las `normas de codificación`_
  vigentes en el proyecto.

* Deberá confeccionarse una *guía para el desarrollador* que
  documente cómo usar las funcionalidades. El idioma en el que se
  confeccione esta guía será preferentemente el **inglés**.

* La documentación de desarrollo que se genere deberá
  estar en formato ReST_.
  

Como iniciar los tramites
============================

Si está interesado en que su desarrollo sea un *proyecto oficial de gvSIG*
puede solicitarlo dando de alta un *ticket* o *boletin* en la 
`página habilitada para solicitudes de proyectos oficiales`_ en 
la forja de OSOR_.

Describa en unos pocos párrafos la funcionalidad que aporta su desarrollo
en el *ticket* aportando como documentos adjuntos las plantillas de 
`ficha del proyecto`_ y `contactos del proyecto`_. Para rellenar las
plantillas recuerde hacerlo a partir del código fuente de estas. Puede
encontrar `más informacion sobre cómo acceder a los fuentes de un documento aquí`_.

A partir de esto se pondrá en contacto con usted la persona adecuada del 
proyecto gvSIG para llevar la coordinación de las tareas de oficializar su
desarrollo en gvSIG.

.. _ReST: http://docutils.sourceforge.net/rst.html
.. _maven: http://maven.apache.org/
.. _JUnit: http://www.junit.org/
.. _OSOR: http://forge.osor.eu
.. _GPL v2: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
.. _`Creative Commons` : http://creativecommons.org/


.. _`normas de codificación` : /web/reference_catalog/lookupObject?uuid=84a57351f2a4d525623e6dcde182d609
.. _`ficha del proyecto` : /web/reference_catalog/lookupObject?uuid=075e729afb778e8f8018fc81e6b831e5
.. _`contactos del proyecto` : /web/reference_catalog/lookupObject?uuid=aa581c88ee81bd6603ae740aa87586a1
.. _`Ver esquema general de procedimientos de testing`: /web/reference_catalog/lookupObject?uuid=bbd435f4caaa8fe0d0b28f223ed1e852
.. _`Guía para documentar`: /web/reference_catalog/lookupObject?uuid=55653a0583dd9a9cd5571ca4203959a3
.. _`documentación de análisis` : /web/reference_catalog/lookupObject?uuid=fa5c5f964fda12699aa3393ea0d87d62
.. _`README.txt` : /web/reference_catalog/lookupObject?uuid=ea7c9855b5a1c3690eb44b25afc3c8d6
.. _`Project Dependencies` : /web/reference_catalog/lookupObject?uuid=3b996fde2cd63e91ab24b47d62a06e6e
.. _`más informacion sobre cómo acceder a los fuentes de un documento aquí` : /web/reference_catalog/lookupObject?uuid=529fc89cb1d4e7677ed4f3e2a16af644
.. _`página habilitada para solicitudes de proyectos oficiales` : http://forge.osor.eu/tracker/?func=add&group_id=89&atid=899
.. _`Contribuciones y parches al código de gvSIG` : /web/reference_catalog/lookupObject?uuid=b49f9501f8f5740cb3d3d1a5e1b53778
.. _`package.info (Template)` : /web/reference_catalog/lookupObject?uuid=1c2c62ef24ca854671142ef2b774790a

.. list-table:: Registro de cambios
   :header-rows: 1

   * - versión
     - Descripción

   * - 1.1
     - Añadido enlace a una plantilla para el *informe de dependencias*.
     
   * - 1.2
     - Sustituido el enlace a la plantilla del informe de dependencias
       por enlace a un documento que describe como rellenar la plantilla
       del informe de dependencias y de donde obtenerla.

   * - 1.2
     - Añadido enlace a un documento explicativo de como rellenar el 
       README.txt a incluir con los fuentes y donde obtener la
       plantilla de este.

   * - 1.2
     - Añadido enlace a un documento explicativo de que debe entregarse
       como documentación de análisis para el nivel básico, así como 
       enlace a un ejemplo.

   * - 1.2
     - Añadido enlaces a las plantilla de la *ficha del proyecto* y los
       *contactos*
     
   * - 1.2
     - Corregida referencia a nivel *basico* y *avanzado*. En un punto se 
       referenciaban como *minimo* y *alto*.
     
   * - 1.3
     - Rehecho el primer párrafo del documento para
       que exprese mejor lo que es un proyecto
       oficial de gvSIG. 

   * - 1.4
     - Añadido requerimiento de que funcionalidades distintas van en 
       plugins distintos.

   * - 1.5
     - Añadido requerimiento de política relacionada con la versión.
       
   * - 1.5
     - Añadido requerimiento de política relacionada con el nombrado de 
       ficheros de una distribución.
   
   * - 1.5
     - Sustituido el requerimiento de seguir las normas de nombrado de
       clases por el de seguir las normas de codificación.

   * - 1.6
     - Añadido el epígrafe *"Como iniciar los tramites"*.

   * - 1.6
     - Correcciones ortográficas y de sintaxis.

   * - 1.7
     - Subdividida la sección *alcance* en dos, *alcance* y *exclusiones*.
       y añadido enlace a `Contribuciones y parches al código de gvSIG`_

   * - 1.8
     - No se deben sobre escribir librerías de gvSIG.

   * - 1.9
     - Añadidas condiciones sobre la licencia de la documentacion 
       entregada.

   * - 1.10
     - Añadidas la nota de que si no pasa el plan de pruebas en una version
       pierde la enominacion de proyecto oficial (punto 3 de requerimientos
       de testing).

   * - 1.10
     - Añadido que se requiere un gestor de bugs publico para el proyecto 
       (punto 4 de requerimientos de testing).

   * - 1.10
     - Extendidas la descripcion de que documentacion de usuario debe entregarse,
       manual de uso, de instalacion y derechos.
       
   * - 1.11
     - Añadido parrafo sobre que el fichero pom.xml debe estar correctamente 
       cumplimentado.
       
   * - 1.12
     - Añadido requerimiento sobre el instalable a entregar para elproyecto o plugin.