Installing gvSIG is a hybrid mechanism between a native installer, dependent on the platform we are running, and a java installer. The native installer, will install the gvSIG framework, preparing everything necessary in order to start a minimalist installation. The second, the java installer, is responsible for presenting the user the different packages available for installation, and installed.

The whole system is based on plugins installation packages, bundles and how they are installed.

We find:

• The native installer.

• Install Packages plugins, a plugin for each package, * files *. gvspkg

  System Message: WARNING/2 (<string>, line 23); backlink

  Inline emphasis start-string without end-string.

• Set of packages, which contain several installation packages plugins, gvspks files.

• References to package plugins files that contain gvspki Basic data of the package along with the URL from where to download this.

A distribution of gvSIG is formed by the native installer, and a package set, gvspks, which added to the minimal installation a set of features we want to be in distribution.

They are available to those who need it, the mechanisms for creating gvSIG distributions with a custom packages sets, so that packages can be included as considered appropriate, thus creating distributions gvSIG specific or customized for different sectors.

gvSIG supports several types of packages. These packages can install different types of accessories.

Currently there is only one type of package available, the container of plugins. From now on, herein, when referring to packet will always be talking about a package that installs a plugin.

gvSIG has a plugin that allows us to generate a package of a plug installed in that instance of gvSIG. This is a simple way that a developer can generate plugins packages from the same gvSIG on which it is developing.

The packet generation tool will include all information in the folder where live the plugin and also allow us to select other files inside the gvSIG installation, and include an ant script to be executed as post-installation script.

In addition to their own files that make up the plugin, we provide some basic metadata to identify the package. These are:

• Package Code: Is the name used by the folder where you install the plugin into gvSIG. Must be unique and should not have two packages with the same name, unless it were different versions of this.

• Version. The version of the package. Normally follow the following schedule:

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

  It is very important that no two versions of the same different package with the same version number.

• Package name: This is the name displayed to the user. By convention this should always be in English.

• Package description: Describes the functionality provided by the package. By convention this should always be in English.

• Owner: Organization/person name who owns the content of package.

• Source code url: Which contains the url where to find the plugin source code.

• Dependencies: With the specification of the package dependencies over other packages.

• Operating system: Contain information on the operating system on which you can run this package. For now, systems supported OS are "Windows", "Linux" and "All". his is important for packages that need native libraries for implementing some of their tasks.

• Architecture: Indicates the hardware architecture for which is designed the package, usually will x86 and x86_64.

• Jvm: Indicates the minimum version of Java Runtime Environment package required to operate.

package required to operate.

• Official, that indicate whether a package is official or not.

In the plugin directory, there will be a * file * package.info with all this information, as well as a folder * install * the script ant to the post-installation called * install.xml *, and all this is packaged in a zip file with relative paths to the folder where you live in the plugin.

Keep in mind that this zip file should never contain folder entries, only files. So if you create a package by hand without using the tool provided by gvSIG we tell the command * zip * the appropriate option to not include them.

To create our own packages of our plugins, simply will be compressed in a zip file the folder where the plugin, making sure they exist, the file * package.info *, the * install folder * and the file * install / install.xml * if we need it.

Once we created our package we can install it using the installer is completed, or we can serve for inclusion in a gvSIG custom installation.

Here is an example of what would contain an install package. Let specifically see the plugin install support for ECW in 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
$ 

We observed that we have the file package.info containing the description of the package:

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

In addition to this there is a folder install with a file Install.xml, which contains the post-installation script of the package and a folder files, a folder with the files that should go elsewhere gvSIG installation of the outside of the folder plugin. The post-install script takes care of copying the files native to where it belongs and in this case set the symlinks to work native libraries correctly installed:

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

The other files that appear are the plugin files themselves, their jars and resource files that may need such as the config.xml. In this case find:

• lib/org.gvsig.raster.ermapper.app-2.0.0-SNAPSHOT.jar. It contains the extension associated with the plugin, used to log into your * * Initialize the new data provider library for raster.
• lib/org.gvsig.raster.ermapper.io-2.0.0-SNAPSHOT.jar the implementation of new data provider.
• lib/org.gvsig.jecw-2.0.0-SNAPSHOT.jar, the java bridge library to the libraries native needed by the plugin.
• config.xml, the configuration file of the plugin.

Each plugin will provide the files needed for their operation.

Una vez tenemos nuestro paquete, podemos entregarlo a nuestros usuarios o solicitar que sea incluido en el repositorio de paquetes de gvSIG, lo que es altamente recomendable, ya que de esta forma damos acceso a él a cualquier usuario que pueda estar interesado en él.

Para hacerlo tendremos que preparar un fichero índice con la extensión gvspki. Este fichero es en un zip similar al gvspkg pero que solo contendrá el fichero package.info con una ligera modificación. El fichero package.info, además de los datos descritos en el apartado anterior tendrá una entrada download-url, que será la URL desde la que poder descargar el paquete, gvspkg, por lo que antes de crear el fichero gvspki deberemos tener claro dónde vamos a alojar nuestro paquete, y una vez construido el fichero gvspki haremos llegar este a gvSIG para que se incluya en el repositorio.

Estos paquetes que solicitamos que se integren en el repositorio de gvSIG solo tienen que cumplir unas pequeñas reglas, principalmente de nombrado y versionado del paquete, no siendo preciso que sean desarrollos oficiales, siendo así una forma fácil de distribuir nuestros desarrollos entre los usuarios.

Puede encontrar más información sobre cómo puede solicitar incluir su paquete en el repositorio de gvSIG en Añadir un paquete al repositorio de paquetes de gvSIG.

Tal como vimos en el apartado Paquetes y conjuntos de paquetes vamos a ver ahora que es lo que contiene el fichero indice del paquete que añade el soporte para el formato ECW:

$ unzip -l gvSIG-desktop-2.0.0-org.gvsig.raster.ermapper.app-2.0.0-SNAPSHOT-23-devel-lin-x86-j1_5.gvspki
Archive:  gvSIG-desktop-2.0.0-org.gvsig.raster.ermapper.app-2.0.0-SNAPSHOT-23-devel-lin-x86-j1_5.gvspki
  Length     Date   Time    Name
 --------    ----   ----    ----
      505  07-08-11 09:47   org.gvsig.raster.ermapper.app/package.info
 --------                   -------
      505                   1 file
$

Como podemos obserbar unicamente tiene un archivo, y es el package.info. Este archivo cotendra:

#
#Fri Jul 08 09:47:36 CEST 2011
state=devel
name=Formats: Ecw format support
buildNumber=23
official=true
code=org.gvsig.raster.ermapper.app
download-url=http\://downloads.gvsig.org/download/gvSIG-desktop/pool/org.gvsig.raster.ermapper.app/gvSIG-desktop-2.0.0-org.gvsig.raster.ermapper.app-2.0.0-SNAPSHOT-23-devel-lin-x86-j1_5.gvspkg
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

Como vemos contiene la misma informacion que el package.info del fichero gvspkg mas una entrada indicando donde se encuentra este, download-url.

Además de generar el paquete para nuestro plugin y solicitar que este sea añadido al repositorio de paquetes de gvSIG, puede resultarnos útil generar un conjunto de paquetes, gvspks con los distintos paquetes que estemos interesados en hacer llegar a nuestros usuarios, de forma que podamos dar un juego de funcionalidades personalizado.

Para eso bastara con crear un fichero zip en el que incluyamos los paquetes, gvspkg, o referencias a paquetes, gvspki que nos interese. Además dentro de este fichero zip podemos incluir información sobre qué paquetes queremos que estén marcados como recomendados o a instalar por defecto, cuando el usuario intente utilizarlo para instalarse nuevas funcionalidades desde él.

Para conseguir esto tendremos que crear un fichero de nombre "defaultPackages" en el que indicaremos, el nombre de los paquetes que queremos que sean marcados como paquetes recomendados o por defecto (uno por línea).

Cada línea tendrá el formato:

code[#versión[#build]]

De forma que presentará como paquete recomendado el que tenga el código de la versión y build que hayan sido indicados.

¿Qué queremos decir con paquete recomendado o marcado por defecto ?

Si durante el proceso de instalación de la aplicación se utiliza un gvspks en el que tenemos una entrada "defaultPackages", los paquetes que ahí se indiquen se marcarán como seleccionados de forma automática para que se instalen. Es una forma de ofrecer al usuario una instalación típica de paquetes en función de los paquetes disponibles.

Si, una vez instalada la aplicación, entramos en el instalador de complementos, este nos presentará en un color distinto los paquetes que se indiquen en el fichero "defaultPackages" del gvspks que se esté usando, de forma que el usuario pueda ser consciente de qué paquetes es recomendado que tenga instalados.

Hay que tener en cuenta que los paquetes que formen nuestro conjunto de paquetes pueden ser tanto paquetes en sí mismos como referencias a paquetes. Esto nos brinda la posibilidad de incluir de base una serie de funcionalidades, y referenciar a otras que se encuentren en la web y que se descargarán bajo demanda si el usuario solicita instalarlas.

Una vez hemos sido capaces de crear el paquete para nuestro plugin, así como de crear un conjunto de paquetes que nos permita ofrecer a nuestros usuarios un juego de funcionalidades personalizado, nos sería útil empaquetar todo esto en un solo instalable de gvSIG para facilitar la descarga e instalación de nuestra distribución personalizada.

El mecanismo de instalación de gvSIG permite hacer esto. Para ello disponemos de utilidades para incluir un gvspkgs dentro del instalable nativo de gvSIG, de forma que este lo extraiga y utilice automáticamente durante el proceso de instalación, así como que lo deje preparado para ser usado por el instalador de complementos cuando concluya la instalación.

Además de incluir nuestro conjunto de paquetes, también nos permitirá añadir los instalables del jre a utilizar por la aplicación para que el usuario no precise descargarselo, en caso de que no disponga de la versión adecuada de el.

Dentro de la carpeta "scripts" del plugin org.gvsig.mkmvnproject, encontraremos:

• Un fichero gvspkg. Se trata de un script python que nos permitirá manipular los paquetes y conjuntos de paquetes.
• Una carpeta gvspkg.bin con los ficheros de configuración necesarios y los binarios necesarios para manipular el instalable nativo de gvSIG.

Antes de utilizar esta utilidad copiaremos la carpeta gvspkg.bin a nuestro home con el nombre ".gvspkg.bin", y nos aseguraremos que el script gvspkg está en el path.

Supongamos que tenemos los archivos:

• El instalador nativo de gvsig para linux, gvSIG-desktop-2.0.0-2030-devel-lin-x86-online.bin , que podremos descargar desde la web de gvsig.
• El conjunto de paquetes que hemos personalizado para nuestra instalación, packages.gvspks.

Ejecutaremos el comando:

gvspkg mkinstall gvSIG-desktop-2.0.0-2030-devel-lin-x86-online.bin packages.gvspks

Esto nos creara el fichero gvSIG-desktop-2.0.0-2030-devel-lin-x86-custom.bin partiendo de nuestro instalador nativo e insertando en el nuestro packages.gvspks.

Si además queremos que se incluya el instalador del jre en el paquete, tendremos que conseguir primero el archivo de instalación correspondiente. Podemos descargarlo desde:

https://downloads.gvsig.org/download/gvsig-desktop/runtimes/java1.6/

Allí encontraremos:

- jre-6u26-linux-i586.bin
- jre-6u26-windows-i586-s.exe

Con los instalables del jre de java para windows y linux.

Así para generar nuestro instalable para linux ejecutariamos:

gvspkg mkinstall --jrelin=./jre-6u26-linux-i586.bin --addjrelin gvSIG-desktop-2.0.0-2030-devel-lin-x86-online.bin packages.gvspks

Y nos crearía gvSIG-desktop-2.0.0-2030-devel-lin-x86-custom-withjre.bin con el instalable del jre incluido y nuestro conjunto de paquetes personalizado.

Si quisiésemos generar los binarios para windows ejecutariamos:

gvspkg mkinstall --jrewin=./jre-6u26-windows-i586-s.exe --addjrewin gvSIG-desktop-2.0.0-2030-devel-win-x86-online.bin packages.gvspks

Generándose el fichero gvSIG-desktop-2.0.0-2030-devel-win-x86-custom-withjre.exe .

Para crear un paquete que contenga nuestro plugin la aplicacion gvSIG dispone de un asistente. Este asistente se encuentra en el menu Herramientas opcion Desarrollo, y requiere que el plugin ya se encuentre desplegado sobre su misma instancia de gvSIG. Vamos a ver cuales serian los pasos para generar un paquete de forma simple.

1. Lo primero deberemos haber desplegado nuestro plugin sobre una instancia de gvSIG. Para la prueba vamos a generar un paquete de instalacion del plugin org.gvsig.centerviewpoint.

2. Con el plugin desplegado ejecutaremos gvSIG y seleccionaremos la opcion de menu "Herramientas -> Debvelopment -> Crear paquete de instalacion de plugin".

   

3. Ahora seleccionaremos el plugin org.gvsig.centerviewpoint de la lista de plugins que nos muestra el asistente.

   

   Seleccion de plugin

   y pulsaremos en siguiente.

4. Ahora nos preguntara por los datos del paquete, que son los que describimos en el apartado Paquetes y conjuntos de paquetes.

   

   Datos del paquete

   Una vez rellenados los datos del paquete correctamente, pulsaremos en siguiente.

5. Se nos preguntara si queremos habilitar el modo avanzado. En general contestaremos que no dejando el check sin marcar.

   Tip

   El modo avanzado no sera necesario siemrpe que todos los archivos que precise nuestro plugin para funcionar se encuentren en la propia carpeta del plugin, y mientras no necesitemos ejecutar codigo especifico mediante el script de post-instalacion.

   

   No activamos el modo avanzado.

   Le daremos siguiente para continuar con el asistente.

6. Ahora se nos preguntara por el archivo de salida. Por defecto nos ofrecera un nombre para el paquete siguiendo las reglas de nombrado usadas en gvSIG y ofreciendonos como carpeta donde dejarlo la carpeta install de la instalacion de gvSIG. Asi mismo nos pregunta si queremos crear tambien el archivo indice gvspki. Si no se lo ponemos nos generara el fichero del paquete con el que podremos probar si se instala correctamente nuestro plugin o pasarselo a nuestros usuarios para que lo instalen.

   

   Archivos de salida sin indice

   Si queremos generar el fichero indice, gvspki, deberemos tener clara bajo que URL va a ser accesible el paquete, para introducir esta en nuesto indice. Asi marcariamos la opcion Crear indice, y en URL de descarga introduciriamos la url completa de donde descargar el fichero gvspkg que vamos a generar.

   

   Archivos de salida con indice

   Una vez completado el formulario, daremos a siguiente para que se inicie la generacion de los ficheros del paquete.

En caso de que necesitemos incorporar en nuestro paquete archivos que estan fuera de la carpeta de nuestro plugin, o precisemos ejecutar codigo en el script de postinstalcion, en el momento que se nos presenta la opcion de si queremos habilitar el modo avanzado lo marcaremos.

Imaginemos que queremos generar un paquete para el plugin de GPE que precisa actualizar la libreria que lleva gvSIG de base kxml de la version 2.2.2 a la version 2.2.3. Para esto hariamos:

1. Seleccionaremos el plugin de GPE

2. Rellenaremos los datos relativos a este plugin.

3. Marcariamos el check de habilitar el modo avanzado

   

   Activamos el modo avanzado.

4. Se nos presentara un arbol con la estructura de archivos de la instalacion de gvSIG para que seleccionemos los que precisemos. Iremos al directorio lib y seleccionaremos kxml2-2.2.2.jar

   Y pulsaremos en siguiente.

5. Nos aparecera un panel con el script de post-instalacion por defecto, que se encarga de copiar los ficheros seleccionados al sitio adecuado.