:Version: 2.0

.. contents::

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:

.. list-table:: Cambios en los artifactId
   :header-rows: 1

   * - artifactId (2.0)
     - classifier (2.0)
     - artifactId (2.1)

   * - org.gvsig.projection
     - 
     - org.gvsig.projection.api

   * - org.gvsig.projection
     - cresques-impl
     - org.gvsig.projection.cresques.impl

   * - org.gvsig.projection
     - cresques-ui
     - org.gvsig.projection.cresques.ui

   * - org.gvsig.fmap.mapcontext
     - 
     - org.gvsig.fmap.mapcontext.api

   * - org.gvsig.fmap.mapcontext
     - impl
     - org.gvsig.fmap.mapcontext.impl

   * - org.gvsig.fmap.mapcontext
     - operation
     - org.gvsig.fmap.mapcontext.operation

   * - org.gvsig.fmap.dal
     -
     - org.gvsig.fmap.dal.api

   * - org.gvsig.fmap.dal
     - spi
     - org.gvsig.fmap.dal.spi

   * - org.gvsig.fmap.dal
     - impl
     - org.gvsig.fmap.dal.impl

   * - org.gvsig.fmap.dal.db
     - 
     - org.gvsig.fmap.dal.db.lib

   * - org.gvsig.fmap.dal.db
     - jdbc
     - org.gvsig.fmap.dal.db.jdbc

   * - org.gvsig.fmap.dal.index.spatial
     - gt2
     - org.gvsig.fmap.dal.index.spatial.gt2

   * - org.gvsig.fmap.dal.index.spatial
     - jts
     - org.gvsig.fmap.dal.index.spatial.jts

   * - org.gvsig.fmap.dal.index.spatial
     - jsi
     - org.gvsig.fmap.dal.index.spatial.jsi

   * - org.gvsig.fmap.dal.file
     -  
     - org.gvsig.fmap.dal.file.lib

   * - org.gvsig.fmap.dal.file
     - store.dbf
     - org.gvsig.fmap.dal.file.dbf

   * - org.gvsig.fmap.dal.file
     - store.shp
     - org.gvsig.fmap.dal.file.shp

   * - org.gvsig.fmap.geometry
     - 
     - org.gvsig.fmap.geometry.api

   * - org.gvsig.fmap.geometry
     - impl
     - org.gvsig.fmap.geometry.impl

   * - org.gvsig.fmap.geometry
     - operation
     - org.gvsig.fmap.geometry.operation

   * - org.gvsig:org.gvsig.compat
     - 
     - org.gvsig.compat.api

   * - org.gvsig:org.gvsig.compat
     - se
     - org.gvsig.compat.se

   * - org.gvsig.app
     - 
     - org.gvsig.app.mainplugin

   * - org.gvsig.coreplugin
     - 
     - org.gvsig.coreplugin.app.mainplugin

   * - org.gvsig.geodb
     - 
     - org.gvsig.geodb.app.mainplugin

   * - org.gvsig.editing
     - 
     - org.gvsig.editing.app.mainplugin

   * - org.gvsig.exportto.app.extension
     - 
     - org.gvsig.exportto.app.mainplugin

   * - org.gvsig.help
     - 
     - org.gvsig.help.app.mainplugin

   * - org.gvsig.i18n.extension
     - 
     - org.gvsig.i18n.app.mainplugin

   * - org.gvsig.annotation.app.extension
     - 
     - org.gvsig.annotation.app.mainplugin

   * - org.gvsig.newlayer.app.extension
     - 
     - org.gvsig.newlayer.app.mainplugin


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:


.. list-table:: Propiedades usadas en los poms
   :header-rows: 1

   * - Nombre
     - Descripcion
     - Valor
     - Definida en

   * - gvsig.product.folder.path
     - Carpeta en la que se van a desplegar gvSIG y los plugins 
       que compilemos.
     - ${basedir}/target/product
     - org.gvsig.desktop

   * - gvsig.desktop.children.version
     - Version del proyecto org.gvsig.desktop y todos sus proyectos hijos
       que se encuentran en el SVN de gvsig-desktop.
     - 2.0.10-SNAPSHOT
     - org.gvsig.desktop

   * - gvsig.package.info.state
     - 
     - devel
     - org.gvsig.desktop.plugin

   * - gvsig.package.info.official
     - 
     - false
     - org.gvsig.desktop.plugin

   * - gvsig.package.info.operatingSystem
     - 
     - All
     - org.gvsig.desktop.plugin

   * - gvsig.package.info.architecture
     - 
     - All
     - org.gvsig.desktop.plugin

   * - gvsig.package.info.javaVM
     - 
     - j1_5
     - org.gvsig.desktop.plugin

   * - gvsig.package.info.gvSIGVersion
     - 
     - 2.0.0
     - org.gvsig.desktop.plugin

   * - gvsig.package.info.poolURL
     - 
     - http://downloads.gvsig.org/download/gvsig-desktop/pool
     - org.gvsig.desktop.plugin

   * - gvsig.package.info.dependencies
     - 
     - required: org.gvsig.app.mainplugin -ge 2.1.0
     - org.gvsig.desktop.plugin

   * - gvsig.package.info.owner
     - 
     - gvSIG Association
     - org.gvsig.desktop.plugin

   * - gvsig.package.info.sourcesURL
     - 
     - ${project.scm.url}
     - org.gvsig.desktop.plugin

   * - gvsig.package.info.webURL
     - 
     - http://www.gvsig.com
     - org.gvsig.desktop.plugin

   * - gvsig.package.info.categories
     - 
     - 
     - org.gvsig.desktop.plugin

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.

.. list-table:: Cambios en los nombres de plugins
   :header-rows: 1

   * - gvSIG 2.0
     - gvSIG 2.1

   * - org.gvsig.app
     - org.gvsig.app.mainplugin

   * - org.gvsig.coreplugin
     - org.gvsig.coreplugin.app.mainplugin

   * - org.gvsig.geodb
     - org.gvsig.geodb.app.mainplugin

   * - org.gvsig.editing
     - org.gvsig.editing.app.mainplugin

   * - org.gvsig.exportto.app.extension
     - org.gvsig.exportto.app.mainplugin

   * - org.gvsig.help
     - org.gvsig.help.app.mainplugin

   * - org.gvsig.i18n.extension
     - org.gvsig.i18n.app.mainplugin

   * - org.gvsig.annotation.app.extension
     - org.gvsig.annotation.app.mainplugin

   * - org.gvsig.newlayer.app.extension
     - org.gvsig.newlayer.app.mainplugin

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*"::

  
    ...
    
    
    
    ...
  

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::

    
      gvsig-plugin-package
      
        zip
      
      ${project.artifactId}
      true
      
        
          target/${project.artifactId}-${project.version}.jar
          lib
        
        
          target/package.info
        
      

      
        
          src/main/resources-plugin
          .
        
      

      
        
          false
          false
          lib
          
            ...
          
        
      

    

  Sustituyendo la linea::

    ...

  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.

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

   * - versión
     - Descripción

   * - 2.0
     - En *introduccion*, el punto que dice "Los proyectos de tipo 
       *plugin de gvSIG*" se ha eliminado.
    
   * - 2.0
     - En *introduccion*, el punto que que habla de la eliminacion de perfiles
       ha sifo modificado.
       
   * - 2.0
     - En *Cambios en los poms: perfiles y propiedades*, donde hacia referencia
       a la propiedad "gvsig.package.info.baseDownloadURL" ahora hace referencia
       a "gvsig.package.info.poolURL" cambiando tambien su valor.
       
   * - 2.0
     - En *Cambios en los poms: perfiles y propiedades*, Se ha añadido al final
       un parrafo comentando la introduccion de perfiles para la comilacion
       de los plugins de gvSIG.
       
   * - 2.0
     - La seccion *Cambios en los poms: package e install de un plugin de gvSIG*, 
       Ha sido simplificada.
       
   * - 2.0
     - En *Poniendolo todo junto*, el punto "En los poms de los proyectos que 
       sean plugins de gvSIG añadiremos" se elimina.