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.