Introduccion

En paralelo a la salida de la version 2.0 de gvSIG se han estado haciendo trabajos de reestructuraion de los proyectos que componen el nucleo de gvSIG 2. Han ido encaminados a dotar de la estructura de maven a todos los proyectos que forman el workspace principal de gvSIG asi como disponer de un proyecto multimodulo maven que englobase a todos estos, en el que la estructura de proyectos y de carpetas coincidiese. Tambien se ha eliminado la necesidad de que un proyecto maven genere varios artefactos, asi como se han elimnado dependencias entre API e implementacion de algunos proyectos o con la implementacion de algunos otros.

Los cambios que se han llevado a cabo afectan principalmente a los poms y en menor grado a los fuentes.

Se ha procurado mantener compatibiliad a nivel de APIs, no modificando ninguno de forma que sea incompatible con la version 2.0. De esta forma los plugins de gvSIG compilados para la version 2.0 seguiran funcionando con la nueva version de gvSIG.

Los cambios mas relevantes que se va a encontrar son:

• Cambios en los poms.
  • Cambios en los identificadores de los artefactos de maven.
  • Se ha eliminado el uso de clasificadores para generar varios artefectos a partir de un proyecto.
  • Ha cambiado la jerarquia de los poms del proyecto.
  • Se ha reducido al minimo el uso de perfiles
  • Algunas variables usadas en los poms han cambiado de nombre o ya no estan definidas y otras que se definian dentro de un perfil, ademas, han pasado a definirse dentro de proyecto al eliminarse el perfil.
• Ha cambiado de nombre y ubicacion el fichero distribution.xml
• Cambios en los nombres de plugins
• Cambios en los nombres de paquetes/complementos de los plugins de gvSIG.
• Proyectos que salen fuera del SVN de gvsig-desktop y del workspace principal de gvSIG.
• Cambios en los fuentes... estos normalmente han sido debidos a correccion de errores o ha sido ampliado el API para añadir nuevas funcionalidades.
• Actualizacion de la licencia de gvSIG, de GPL version 2 a version 3.

Vamos a describir un poco los cambios y como afectan al desarrollador que tenga que migrar un desarrollo de la version 2.0 a la 2.1.

Cambios en los poms: artifactsId y clasificadores

Los cambios en los artifactId de maven vienen dados principalmete al tener que eliminar que un proyecto produzca mas de un artefacto. Cuando esto se daba, lo que se ha hecho ha sido crear un proyecto padre con un subproyecto por artefacto que se generaba. Por ejemplo, antes teniamos un proyecto "libFMap_dal/org.gvsig.fmap.dal" y generaba los jars: Migración de proyectos de gvSIG 2.0.0 a gvSIG 2.1.0 - org.gvsig.fmap.dal-2.0.jar - org.gvsig.fmap.dal-2.0-impl.jar - org.gvsig.fmap.dal-2.0-spi.jar

Ahora el proyecto se ha dividido en los siguientes proyectos:

• org.gvsig.fmap.dal
  • org.gvsig.fmap.dal.api
  • org.gvsig.fmap.dal.impl
  • org.gvsig.fmap.dal.spi

Los fuentes que antes estaban en un solo proyecto han sido divididos en tres proyectos, generando cada uno de ellos su correspondiente jar.

Ademas de este tipo cambios en los artifactId, que se dan principalmente en las librerias del proyecto, tambien han cambiado algunos artifactId de los proyectos de tipo plugin. Se ha normalizado el nombre y estructura de los plugins de gvSIG que habia en el SVN de gvsig-desktop.

Podemos ver los artifactId que han cambiado en la siguiente tabla:

Cambios en los poms: la jerarquia de proyectos

La jerarquia de proyectos en la version 2.0 era poco intuitiva. Teniamos una serie de proyectos como:

• org.gvsig.maven.base.build
• org.gvsig.maven.base.extension.pom
• org.gvsig.maven.base.jni.pom
• org.gvsig.maven.base.pom
• gvsig-base-extension-pom
• gvsig-base-library-pom
• gvsig-base-library-jni-pom
• gvsig-base-pom
• gvsig-base
• gvsig-standard
• org.gvsig.core.maven.dependencies

Entre los que en el mejor de los casos resultaba dificil navegar o controlar que jerarquia habia entre ellos y de quien debiamos extender para crear nuestro proyecto, contribuyendo a ello que la jerarquia de carpetas no se correspondia con la de proyectos.

Lo que se ha hecho ha sido redistribuir la funcionalidad que habia en esos proyectos en seis proyectos, haciendo coincidir su estructura con la de carpetas. Los proyectos serian:

└── org.gvsig.desktop
    ├── org.gvsig.desktop.compat.cdc
    │
    ├── org.gvsig.desktop.framework
    │
    ├── org.gvsig.desktop.installer
    │
    ├── org.gvsig.desktop.library
    │
    └── org.gvsig.desktop.plugin

Estos proyectos representan los distintos tipos de proyecto que nos vamos a encontrar en gvSIG. En cada uno de ellos podemos encontrar:

• org.gvsig.desktop, se trata del proyecto del que extienden todos los proyectos de gvSIG y del que deberemos extender para crear nuestros proyectos. Define la configuracion de algunos plugins de maven y las versiones de las librerias que usa gvSIG, asi como la de las librerias del nucleo de gvSIG.
• org.gvsig.desktop.plugin contiene toda la configuracion necesaria para compilar, empaquetar e instalar nuestro plugin de gvSIG. Ademas, son proyectos hijos de este, y por tanto los podemos encontrar en esa misma carpeta en el SVN, todos los proyectos de tipo plugin que forman el nucleo de gvSIG.
• org.gvsig.desktop.compat.cdc, contiene la configuracion de los proyectos de gvSIG que deben ser compatibles con java-cdc y en esa carpeta encontraremos esos proyectos.
• org.gvsig.desktop.library, tiene la configuracion para las librerias de gvSIG. Este proyectos apenas contiene configuracion ya que la configuracion necesaria para una libreria es basicamente la contenida en org.gvsig.desktop, asi que basicamente actua como un contenedor de estas.
• org.gvsig.desktop.framework, actua como contenedor del proyecto de andami y andami.updater.
• org.gvsig.desktop.installer, contiene la configuracion necesaria para generar los instalables de gvSIG.

Un pequeño comentario para los que vayan a compilar gvSIG desktop completo. En la version 2.0 para compilar gvSIG nos descargabamos la carpeta build y de ahi empezabamos a trabajar. Con la version 2.1 esto cambia. Ahora ya no existe la carpeta build. Para compilar gvSIG desktop nos descargaremos la carpeta org.gvsig.desktop, y simplemente ejecutaremos un "mvn install" de esta. Si vamos a trabajar con eclipse, precisaremos tener instalado el plugin de eclipse m2e.

Bien, con "mvn install" se compila todo gvSIG.... ¿ Y donde quedan los binarios de gvSIG ?

Pues segun. Si es la primera vez que compilamos gvSIG, estos quedaran en la carpeta target/product. Cuando compilamos gvSIG se comprueba si existe en el "home" del usuario un fichero ".gvsig-devel.properties" en el que indique donde hay que desplegar gvSIG, y si no existe lo crea indicando que se desplegara sobre la carpeta "org.gvsig.desktop/target/product" desde la que hemos lanzado la compilacion.

Cambios en los poms: perfiles y propiedades

En los poms de los proyectos de gvSIG habian definidas una serie de propiedades que tenian varios usos. En la configuracion actual las unicas propiedades relevantes que hay son:

Basicamente, si obserbamos la tabla anterior, veremos que se utiliza unicamente la variable gvsig.product.folder.path, que indica donde se desplegaran nuestros plugins de gvSIG y las variables gvsig.package.info, que son utilizadas para configurar el paquete asociado a nuestro plugin. Sobre estas comentar, que aunque en el proyecto org.gvsig.desktop.plugin se inicializan por defecto, en cada plugin deberan ser sobreescritas con los valores adecuados al plugin, y señalar que estas propiedades ya existian en la 2.0, pero han cambiado de nombre. Antes se llamaban algo como "package.info..." y ahora se les ha añadido delante "gvsig...." pero siguen teniendo el mismo significado que tenian en la version 2.0.

En relacion al uso de "profiles" en los proyectos maven, la regla general es que estos han desaparecido. El uso principal de estos dentro de gvSIG era para:

• Distinguir entre compilacion compatible javase y javacdc. Ahora simplemento se usa una configuracion distinta para unos proyectos que para otros, teniendo los proyectos que deben ser compatibles CDC un ancenstro comun en el que tener esa configuracion.
• Lanzar algunas tareas especificas de configuracion de eclipse. Ahora ya no se usan "launchers" especiales para ejecutar o compilar los proyectos. En su lugar usaremos directamente el plugin de eclipse m2e, con lo que ya no es necesario el uso de estos profiles.
• Configurar y activar opciones especiales que permitan desplegar los plugins de gvSIG correctamente. Esto ya no es necesario ya que se ha integrado en las fase de "package" e "install" de maven.

El uso de perfiles para estas tareas se ha eliminado de los proyectos de gvSIG, asi que no deberia ser necesario usarlos. Eso si, antes de eliminar los perfiles de su proyecto compruebe que no se declaran propiedades en ellos que vayan a ser usadas desde alguna otra parte, como por ejemplo las propiedades "package.info" usadas para la configuracion del "package.info".

Se ha introducido el uso de perfiles para identificar de forma correcta a los proyectos que despliegan plugins de gvSIG. De forma que los plugins de maven especificos de procesar plugins de gvSIG solo se activan cuando se encuntra en fichero "buildNumber.properties" en la carpeta del proyecto.

Cambios en los poms: package e install de un plugin de gvSIG

Con la nueva configuracion que hay en los proyectos base cuando tengamos un proyecto de tipo plugin de gvSIG este debera extender de org.gvsig.desktop.plugin. Con esto heredaremos toda la configuracion necesaria para empaquetar e instalar nuestro plugin.

Un "mvn package" dejara el paquete resultante en la carpeta target de nuestro proyecto.

Para que el plugin se despliegue contra la instalacion de gvSIG deberemos hacer algo mas. Tendremos que ir a nuestra carpeta de usuario, en linux $HOME y cercionarnos de que tenemos un fichero ".gvsig-devel.properties" en el que haya una variable "gvsig.product.folder.path" declarada y con el valor de donde esta la instalacion de gvSIG en la que hay que desplegar los plugins. Con esto asi, un "mvm install" nos desplegara el plugin en ese carpeta.

El fichero distribution.xml y recursos del plugin

Cuando compilamos un proyecto de tipo libreria, normalmente todos los recursos van a parar al jar asociado a esta libreria. Sin embargo cuando compilamos un proyecto de tipo plugin de gvSIG, los recursos igual pueden ir a parar al jar como a la carpeta en la que se instala el plugin. En la version 2.1 de gvSIG, se han separado los recursos que van a un lado y los que van a otro. Asi los recursos que van al jar se dejaran en la carpeta src/main/resources, de forma que maven los gestiona en su ciclo natural y los incluya en el jar. Y los recursos que van a la carpeta del plugin los dejaremos en la carpeta src/main/plugin-resources, manteniendo en esta carpeta la estructura que tendran en la carpeta del plugin una vez instalado, y facilitando asi el empaquetado y despliegue de nuestro plugin.

Junto con el cambio de hubicacion de algunos recursos, tambien ha cambiado el fichero "distribution.xml", que ha sido movido a src/main/assembly/gvsig-plugin-package.xml eliminandose la carpeta distribution. Ha cambiado la forma en como se empaqueta, antes se usaba como "format", "dir" y ahora usamos "zip". Ya no se emapaqueta directamente sobre la carpeta en la que se despliega el plugin, si no en un fichero zip en la carpeta target de nuestro plugin, manteniendo en este la estructura que tiene el paquete/complemento de nuestro plugin. Sera en la fase de install cuando el plugin se despliegue sobre la instalacion de gvSIG.

Comentar tambien que antes se generaba en el raiz de nuestro proyecto el fichero package.info, y ahora este se generara en la carpeta target.

Si quisiesemos seguir empaquetando como se hacia en la version 2.0, deberiamos sobreescribir la configuracion del plugin maven-assembly-plugin completa para seguir invocando a nuestro distribution.xml.

Cambios en los nombres de plugins

La siguiente tabla reflaja los cambios que han habido en nombres de plugin.

Para mantener el impacto de este cambio lo mas bajo posible, ademas de hacer cambios en la implementacion encargada del manejo y carga de los plugins, se ha intruducido una nueva propiedad en el "config.xml" de los plugins que nos permita declarar nombres alternativos para el plugin. De esta forma, los plugins que han cambiado de nombre declaran como nombre alternativo o alias el nombre antiguo. Esto nos permite que los plugins que tenian declaradas dependencias con plugins que han cambiado de nombre puedan seguir resolviendose correctamente. Asi mismo, las funciones de manejo de plugins en PluginsManager y PluginService, son capaces de tratar adecuadamente los nombre de plugin de la version 2.0, y cuando se les pide un plugin usando el nombre de la 2.0 devuelven correctamente la carpeta asociada a ese plugin o la instancia de este aunque haya cambiado de nombre.

La forma en que un plugin especifica un nombre alternativo o alias seria utilizando el tag "alternativeNames" en su "config.xml":

<plugin-config>
  ...
  <alternativeNames name="org.gvsig.app"/>
  <icon src="gvsig-logo-icon" text="gvSIG"/>
  <libraries library-dir="lib"/>
  ...
</plugin-config>

A pesar de las modificaciones en el fuente para reducir el impacto, este cambio afectara a plugins que interactuen con la carpeta de otro plugin directamente, sin pasar por el API para obtener el File asociado a la carpeta del plugin.

Proyectos que salen fuera del workspace principal de gvSIG

Ademas de cambiar la estructura de los proyectos del SVN principal de gvSIG, hay algunos proyectos que salen de el para pasar a tener su propio proyecto en la infraestructura de gvSIG con su propio SVN. Algunos ya eran proyectos en el SVN de gvSIG y otros formaban parte de uno o mas proyectos. En general estos proyectos estan formados por los proveedores de datos para algunos formatos junto con sus librerias de apoyo y el plugin que los instala. Los proyectos que aparecen nuevos en la ifraestructura de desarrollo de gvSIG son:

• org.gvsig.dwg
• org.gvsig.dgn
• org.gvsig.dxf
• org.gvsig.postgresql
• org.gvsig.mysql

Cambios en los fuentes

Ademas de los cambios propios de correccion de errores, deribado de esta reestructuracion de los proyectos se han introducido modificaciones. Dejo aqui una pequeña reseña de estas modificaciones:

• Eliminada la implementacion del GeneralPathX del API de geometrias, r40388
• Añadido a la libreria de geometrias soporte para indices espaciales, r40387 , r40363
• Eliminadas las dependencias de la implementacion de geomerias sobre la libreria de las operaciones r40386 , r40364, r40359,
• Añadido soporte para poder especificar el srs en la conversion a wkb en el GeometryManager, r40366
• Añadido metodos de utilidad en el GeometryManager para crear curve, surface, multicurve y multisurface, r40393
• Añadidos metodos de utilidad en OrientablePrimitive para añadir vertices usando x,y,z en lugar de Point, r40393
• Marcados como deprecated todos los metodos del GeometryManager que trabajan con GeneralPathX, y comentado en su javadoc que se debe usar en su lugar, r40393
• Movido el codigo que habia en appgvsig dependiente de la implementacion proyecciones a la libreria org.gvsig.projection.cresques.ui. Se ha mantenido los mismos nombres de paquetes para no romper compatibilidad con lo que ya habia. r40392, r40398, r40398 y r40400
• En las librerias que debian ser compatibles con java 1.4, se ha corregido algunos fracmentos de codigo que no lo eran, r40358, r40357, r40360, r40370, r40362
• Se han eliminado dependencias con JTS alli donde habian metodos en el API de geometrias que ofrecian la misma funcionalidad, r40394, r40391
• Se ha sustituido en varios puntos la utilizacion del GeneralPathX por el uso del API de geometrias, r40394, r40389
• En varios puntos se ha sustituido la invocacion directa a la libreria de operaciones de geometrias por el uso de metodos de estas r40373 , r40372, r40368, r40394, r40367
• Se ha sustituido en varios puntos la invocacion a la implementacion de geometrias por el uso de metodos del API de estas r40373 , r40372, r40396 .
• Sustituido el uso del Quadtree de jts por el manejo de indices espaciales de la libreria de geometrias, r40371

Cambio de la licencia de gvSIG.

Hemos estado repasando las licencias de las distintas librerias que usa gvSIG, y hemos obserbado algunas incompatibilidades de algunas de ellas con la que usa gvSIG hasta el momento, la GPL2. Muchas de estas incompatibilidades se resuelven en la siguiente version de la GPL, asi que se ha decidido actualizar la licencia de gvSIG de la version 3 de la GPL. De cara al desarrollador, esto, ademas del cambio que pueda implicar la actualizacion de version, supone que van a ser modificados todos los fuentes de gvSIG para actualizar las cabeceras a la GPLv3.

Poniendolo todo junto

Bueno... y todo esto que he contado...

¿ Como afecta a los desarrolladores que quieren migrar su plugin de gvSIG a la version 2.1 ?

Si lo tienen compilado para la 2.0 y quieren distribuirlo deberian poder hacerlo sin mas.

Si quieren compilarlo para la 2.1 para aprovechar alguna de las funcionalidades que se vayan añadiendo tendrian que:

• Modificar los poms para poner como padre de estos a org.gvsig.desktop o org.gvsig.desktop.plugin.

• Si en nuestros poms definimos o usamos las propiedades "package.info" deberemos pasar a nombrarlas "gvsig.package.info".

• Si tenemos definidas propiedades en algun perfil en nuestros poms pasarlas a propiedades de nuestro proyecto.

• Eliminar los perfiles que no sean especificos de nuestro proyecto

• Crearemos el fichero src/main/assembly/gvsig-plugin-package.xml con algo como:

  <assembly>
    <id>gvsig-plugin-package</id>
    <formats>
      <format>zip</format>
    </formats>
    <baseDirectory>${project.artifactId}</baseDirectory>
    <includeBaseDirectory>true</includeBaseDirectory>
    <files>
      <file>
        <source>target/${project.artifactId}-${project.version}.jar</source>
        <outputDirectory>lib</outputDirectory>
      </file>
      <file>
        <source>target/package.info</source>
      </file>
    </files>
  
    <fileSets>
      <fileSet>
        <directory>src/main/resources-plugin</directory>
        <outputDirectory>.</outputDirectory>
      </fileSet>
    </fileSets>
  
    <dependencySets>
      <dependencySet>
        <useProjectArtifact>false</useProjectArtifact>
        <useTransitiveDependencies>false</useTransitiveDependencies>
        <outputDirectory>lib</outputDirectory>
        <includes>
          <include>...</include>
        </includes>
      </dependencySet>
    </dependencySets>
  
  </assembly>
  

  Sustituyendo la linea:

  <include>...</include>
  

  Por las lineas correndientes del "distribution.xml" en las que identificaremos las dependencias que debe llevarse nuestro plugin de gvSIG en su carpeta "lib". En esta lista no incluiremos el jar de nuestro plugin ya que este se copia en otra seccion del assembly. En caso de que no haya que llevarse dependencias podemos eliminar la seccion completa "dependencySet" del assembly.

  y una vez actualizado "gvsig-plugin-package.xml" eliminaremos la carpeta "distribution".

• Actualizaremos los artifactId de nuestros proyectos deacuerdo a la tabla "Cambios en los artifactId" incluida en este documento.

• Nos cercioraremos que no incluimos numeros de version en nuestras dependencias, por lo menos en las que ya aporta gvSIG, para que estas sean tomadas del pom padre, org.gvsig.desktop y se mantengan todas coherentes.

• Eliminaremos el fichero "buildNumber.properties" de todos los proyectos que no vayan a generar plugins de gvSIG (antes era preciso que estuviese creado en los ancestros de estos aunque no se usasen).

Y despues de esto, con un poco de suerte, podremos ejecutar un "mvn clean" de nuestro proyecto para comprobar que se pueden resolver todas las dependencias, y un "mvn install" para compilarlo y deslegarlo.