gvSIG soporta varios tipos de paquetes que pueden instalar diferentes tipos de complementos. Actualmente solo hay disponible un tipo de paquete, el contenedor de plugins. De ahora en adelante, en este documento, cuando nos refiramos a paquete siempre estaremos hablando de un paquete que instala un plugin.

gvSIG dispone de un plugin que nos permite generar un paquete de un plugin instalado en esa instancia de gvSIG. Esto es una forma sencilla de que un desarrollador pueda generar paquetes de sus plugins desde el mismo gvSIG sobre el que está desarrollando.

La herramienta de generación de paquetes se encargará de incluir toda la información que haya en la carpeta donde vive el plugin y además nos permitirá seleccionar otros archivos de dentro de la instalación de gvSIG, así como incluir un script de ant que será ejecutado como script de post-instalación.

Además de los propios ficheros que componen el plugin, deberemos suministrar unos metadatos básicos de cara a la identificación del paquete. Estos son:

• Código del paquete. Es el nombre usado por la carpeta en la que se instala el plugin dentro de gvSIG. Debe ser único y no debería haber dos paquetes con el mismo nombre, salvo que se tratase de versiones distintas de este.

• Versión. Es la versión del paquete. Normalmente seguirá el siguiente esquema:

  mayor[.minor[.revision[-classifier[-build]]]]
  

  Es muy importante que no existan dos versiones del mismo paquete distintas, con el mismo numero de versión.

• Nombre del paquete. Se trata del nombre que se mostrará al usuario. Por convenio este irá siempre en inglés.

• Descripción del paquete, la descripción, en inglés, de las funcionalidades que aporta el paquete.

• Dueño, nombre de la organización/persona propietaria del contenido del paquete.

• URL de los fuentes, que contendrá la url donde encontrar los fuentes del plugin.

• Dependencias. Con la especificación de las dependencias que tiene ese paquete respecto a otros paquetes.

• Sistema operativo. Contendrá la información del sistema operativo sobre el que se puede ejecutar este paquete. De momento, los sistemas operativos soportados son "Windows", "Linux" y "All". Esto es importante de cara a paquetes que aporten librerías nativas para la ejecución de algunas de sus tareas.

• Arquitectura. Indica la arquitectura de hardware para la que esta diseñado el paquete, normalmente sera x86 y x86_64.

• jvm, indicará la versión mínima del entorno de ejecución de java que requiere el paquete para funcionar.

• oficial, que indicará si se trata de un paquete oficial o no.

Dentro del directorio del plugin, existirá un fichero package.info con toda esta información, así como una carpeta install con el script de ant para la post-instalación llamado install.xml, y todo esto se empaquetará en un fichero zip con rutas relativas a la carpeta en la que vive el plugin.

Hay que tener en cuenta que ese fichero zip no debe contener nunca entradas de carpetas, solo ficheros. Con lo que si creamos un paquete a mano sin usar la herramienta suministrada por gvSIG deberemos indicarle al comando zip la opción adecuada para que no las incluya.

Para crear nuestros propios paquetes de nuestros plugins, simplemente tendremos que comprimir en un fichero zip la carpeta donde se encuentra el plugin, asegurandonos de que existan, el fichero package.info, la carpeta install y el fichero install/install.xml si lo necesitamos.

Una vez hemos creado nuestro paquete podemos instalarlo utilizando el instalador de complementos, o nos puede servir para incluirlo en una instalación personalizada de gvSIG.

Veamos un ejemplo de lo que contendria un paquete de instalacion. Vamos a ver concretamente el plugin que instala el soporta para ECW en gvSIG:

$ unzip -l gvSIG-desktop-2.0.0-org.gvsig.raster.ermapper.app-2.0.0-SNAPSHOT-23-devel-lin-x86-j1_5.gvspkg
Archive:  gvSIG-desktop-2.0.0-org.gvsig.raster.ermapper.app-2.0.0-SNAPSHOT-23-devel-lin-x86-j1_5.gvspkg
  Length     Date   Time    Name
 --------    ----   ----    ----
     4092  07-08-11 09:47   org.gvsig.raster.ermapper.app/lib/org.gvsig.raster.ermapper.app-2.0.0-SNAPSHOT.jar
    23391  07-08-11 09:47   org.gvsig.raster.ermapper.app/lib/org.gvsig.raster.ermapper.io-2.0.0-SNAPSHOT.jar
    28206  07-08-11 09:47   org.gvsig.raster.ermapper.app/lib/org.gvsig.jecw-2.0.0-SNAPSHOT.jar
   655809  07-08-11 09:47   org.gvsig.raster.ermapper.app/install/files/native/libNCSUtil.so.0
   430361  07-08-11 09:47   org.gvsig.raster.ermapper.app/install/files/native/libNCSCnet.so.0
    72242  07-08-11 09:47   org.gvsig.raster.ermapper.app/install/files/native/libNCSEcwC.so.0
  6120711  07-08-11 09:47   org.gvsig.raster.ermapper.app/install/files/native/libNCSEcw.so.0
    25851  07-08-11 09:47   org.gvsig.raster.ermapper.app/install/files/native/libjecw2.0.0.so
     1085  07-08-11 09:47   org.gvsig.raster.ermapper.app/install/install.xml
      313  07-08-11 09:47   org.gvsig.raster.ermapper.app/package.info
      363  07-08-11 09:47   org.gvsig.raster.ermapper.app/config.xml
 --------                   -------
  7362929                   12 files
$ 

Podemos obserar que tenemos el fichero package.info que contiene la descripcion del paquete:

#
#Fri Jul 08 09:47:35 CEST 2011
state=devel
name=Formats: Ecw format support
buildNumber=23
official=true
code=org.gvsig.raster.ermapper.app
operating-system=lin
architecture=x86
java-version=j1_5
gvSIG-version=2.0.0
version=2.0.0-SNAPSHOT
type=plugin
description=Ermapper data provider for gvSIG
model-version=1.0.0

Ademas de este obserbamos que existe una carpeta install con un fichero install.xml, que contiene el script de postinstalacion del paquete y una carpeta files con los ficheros que deben ir a parar a otras partes de la instalacion de gvSIG fuera de la carpeta del plugin. El script de postinstalacion se encarga de copiar los ficheros nativos a donde corresponde y en este caso ajustar los enlaces simbolicos que necesite para que funcionen correctamente las librerias nativas que instala:

<project name="org.gvsig.plugin1" default="main" basedir=".">
    <target name="main" depends="copy_files, link"/>
    <target name="copy_files">
        <copy todir="${gvsig_dir}">
            <fileset dir="./files" includes="**"/>
        </copy>
    </target>
    <target name="link" depends="checkos" if="linuxos">
        <exec executable="ln" >
            <arg value="-s"/>
            <arg value="${gvsig_dir}/native/libNCSCnet.so.0"/>
            <arg value="${gvsig_dir}/native/libNCSCnet.so"/>
        </exec>
        <exec executable="ln" >
            <arg value="-s"/>
            <arg value="${gvsig_dir}/native/libNCSEcwC.so.0"/>
            <arg value="${gvsig_dir}/native/libNCSEcwC.so"/>
        </exec>
        <exec executable="ln" >
            <arg value="-s"/>
            <arg value="${gvsig_dir}/native/libNCSEcw.so.0"/>
            <arg value="${gvsig_dir}/native/libNCSEcw.so"/>
        </exec>
        <exec executable="ln" >
            <arg value="-s"/>
            <arg value="${gvsig_dir}/native/libNCSUtil.so.0"/>
            <arg value="${gvsig_dir}/native/libNCSUtil.so"/>
        </exec>
    </target>
    <target name="checkos">
      <condition property="linuxos">
           <os family="unix" />
      </condition>
    </target>
</project>

El resto de ficheros que aparecen son los propios ficheros del plugin, sus jars y ficheros de recursos que pueda necesitar como puede ser el config.xml. En este caso encontraremos:

• lib/org.gvsig.raster.ermapper.app-2.0.0-SNAPSHOT.jar. Que contiene la extension asociada al plugin, usada para registrar en su initializa el nuevo proveedor de datos para la libreria de raster.
• lib/org.gvsig.raster.ermapper.io-2.0.0-SNAPSHOT.jar , la implementacion del proveedor de datos nuevo.
• lib/org.gvsig.jecw-2.0.0-SNAPSHOT.jar, la libreria java de puente con las librerias nativas que precisa el plugin.
• config.xml, el fichero de configuracion del plugin.

Cada plugin llevara detras los ficheros que precise para su propio funcionamiento.