Los cambios entre la versión 1.X y la 2.X llegan a ser muy importantes en 
algunas áreas de la aplicación. Podemos encontrar cambios importantes
relacionados con:

- Construcción del proyecto, se ha pasado de *ant* a *maven*.

- Normalización de nombres de paquetes java.

- Arquitectura de acceso a datos. Se ha reescrito toda la parte
  de `acceso a datos`_ en gvSIG.

- Rearquitectura de la librería de acceso a geometrías.

- Reescritura de los mecanismos usados para la escritura y
  recuperación de los datos en los ficheros de proyecto de gvSIG.
  
- Reescritura de los mecanismos usados para persistir los datos
  de usuario asociados a un *plugin*.

- Cambio del mecanismo de registro usado, pasando de *log4j* a *slf4j*.

- Mecanismo de empaquetado e instalación de *plugins* para gvSIG.

- Introducción de mecanismos para la separación entre API e implementación
  en el código de gvSIG.
  
- Separación de la parte de lógica de la de interface de usuario, esto
  principalmente en las partes de la aplicación que se han reescrito, 
  el interface de usuario, en las partes que no ha sido necesario,
  reescribirlo, se mantienen como estaba.

- Se ha elaborado una `guía de normas de codificación`_ a seguir en el
  código de gvSIG.

A la vista de estos cambios, si nos planteamos la pregunta de *¿ Qué
tenemos que tener en cuenta para iniciar un desarrollo en la línea 1.X
y luego migrar a la línea de la 2 ?*, la respuesta no es simple.

Lo primero que nos surge es que *no se puede mantener
esa compatibilidad*. Si pensamos un poquito más podemos seguir
algunas recomendaciones, unas mas difíciles de seguir que otras. 
Vamos a enumerar algunas de ellas aquí, y que cada cual
decida sobre la posibilidad de aplicarlas en función de su proyecto:

- **Nunca modifiques código fuente de gvSIG**. Aunque pueda parecer
  obvio, no modifiques el código de gvSIG, úsalo. Hay puntos de extension
  en gvSIG que te permiten *pinchar* muchas de las funcionalidades de gvSIG
  para personalizarlas, y si para la que necesitas no lo hay, comentanoslo
  para que estudiemos como darte una solución.

- **Trabaja contra un instalable de gvSIG y no contra las fuentes**. Esto
  realmente sería más que una recomendación. A la hora de desarrollar
  no incrustes tu desarrollo en el *workspace* con los fuentes de gvSIG.
  Crea un *workspace* para tu proyecto que despliegue tus *plugins* sobre
  una instalación de gvSIG.
  
- **Usa maven como mecanismo de construcción**. Existe un repositorio de 
  *maven* para la versión 1.9+ de gvSIG. Si puedes prepara tu proyecto con
  *maven*, siguiendo la estructura multimódulo recomendada para la línea
  de la 2.
  
  No es imprescindible, de hecho, si no estás familiarizado con maven, te
  puede causar más de un dolor de cabeza, pero, en caso de que luego
  quieras migrar a la línea de la 2, será trabajo que llevarás adelantado.
  
- **Mantén separada la implementación del API de las funcionalidades
  que aportes**. Busca un equilibrio entre una implementación monolítica
  y disponer de varias librerías con su API e implementación, de forma que
  las dependencias entre ellas solo estén a través del API de estas.
  
  En caso de querer empezar a hacer esa separación entre API e implementación
  en código para la 1.X, puedes emplear los mecanismos que hay implementados
  en la librería *org.gvsig.tools* de la 2 que funciona también en la línea 
  de la 1.X
  

- **Mantén la parte de acceso a datos dentro de la lógica de tu aplicación**, en la
  parte de la implementación, y dentro de lo posible intenta mantener
  controladas las partes de tu código que acceden a la parte de datos. Cuando pases
  a la versión 2.X tendrás que modificar esas partes de tu aplicación.
  
- **Mantén la parte de acceso a geometrías controlada** en la parte de
  lógica de tu desarrollo. Los cambios en el manejo de geometrías han sido
  importantes en la 2.
  
- **Mantén controlado y documentado qué partes de tu aplicación se graban
  con el proyecto**. Como se guardan los datos en el proyecto
  a cambiado completamente, obligando a declarar qué es lo que se va a
  guardar en el proyecto, con lo que es recomendable que esté bien documentado
  para facilitar el cambio al modelo de proyecto de la 2.

- **Usa como mecanismo de registro el API de slf4j sobre el backend de log4j**.
  Puedes consultar información sobre esto en `Loggin`_

- **Usa el interface clonable**. Cuando tengas que clonar objetos usa este interface
  y sigue las recomendaciones de java para hacerlo. *Nunca uses los mecanismos de
  persistencia del proyecto para clonar un objeto*. Puedes encontrar documentación
  sobre esto en el documento `Clonación de objetos`_.

En general no estaría mal que leyeses los apartados de `Crear un proyecto para gvSIG`_
y `Migración de proyectos a gvSIG 2.0`_ de la guía de desarrollo de gvSIG 2.

.. _`Crear un proyecto para gvSIG` : /web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/crear-un-proyecto-para-gvsig
.. _`Migración de proyectos a gvSIG 2.0` : /web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/howto-migrate-projects-to-gvsig-2-0
.. _`Clonación de objetos` : /web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/howto-migrate-projects-to-gvsig-2-0/object-cloning
.. _`Loggin` : /web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/howto-migrate-projects-to-gvsig-2-0/logging
.. _`acceso a datos` : /web/reference_catalog/lookupObject?uuid=dbe8c0a65f2fd32baa1c48f85df5322d
.. _`guía de normas de codificación` : /web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/coding-development-guidelines/coding-conventions