Before starting the installation process and configuration of all the elements needed to operate gvSIG, it is recommended to review the basic starting points that are needed to make the process of running the application a successful experience.
First, this guide is based on the use of the open source multiplatform integrated development environment Eclipse, on which all the necessary processes for the preparation and support of gvSIG will run. The version that was used in the preparation of this tutorial is 3.2, so it is advisable to use the same version or higher.
It is also necessary to install any of the existing Eclipse plugins for working with Subversion, because there is no default support for developing such functionality. You may use the version of Subclipse or Subversive that is best suited to the version of Eclipse that you installed.
On the other hand, and to ensure the proper functioning of all the components that are used by gvSIG, you will need to have installed version 1.5 or higher of Java Virtual Machine (JVM) from Sun Microsystems. It is important to check that this is a version of SUN, as gvSIG will not function properly on virtual machines from other entities, like the one that comes with the Debian GNU systems. For everything to run well the following must be considered:
Finally, in addition to the Java virtual machine, gvSIG depends on a set of native libraries, among which are GDAL and PROJ. In case of Ubuntu, the libraries to be used are included in the distribution, and those can be installed through the corresponding package manager. The packages to be installed for the proper functioning of gvSIG are:
For Windows or Mac, these libraries will be obtained through Maven when compiling and generating a build of gvSIG.
Once your computer meets these requirements, you can proceed with the installation of Maven and the creation of a workspace for gvSIG, since the other needed elements will be obtained by the built project of the application.
Apart from having a JDK installed, there is no need for any special configuration to begin working with Maven on gvSIG, because the gvSIG build project will install everything that is needed, including Maven.
However, if you want to install Maven yourself, you can download it from the project website and install it following the installation instructions. Keep in mind that Maven version 2.2.1 or higher is required for gvSIG.
You may also need to configure Maven to access the Internet through an HTTP proxy; the configuration is shown on the Maven installation page.
If you use the Maven installation included in the build project, you can find this in the Maven subfolder.
Note
Maven tests in gvSIG are done with the version included in the build project; with another Maven version the build of the project may not function properly.
Whether you install it yourself, or use the version provided by the build project, the subdirectory bin will contain the mvn script, that you can use when you are using Linux, Mac or any other Unix version, and the mvn.bat file for if you are using Windows. The most convenient way (to be able to run it from the console) is by adding the script to the run path (usually by adding the directory build/maven/bin to the PATH variable) so that you can run it from anywhere.
Later on we will describe some common tasks that can be used, either from a console or through the launchers from the External Tools menu in Eclipse.
gvSIG employs several native libraries, which are needed both for compilation and when running the application. Since they are native, you must use those that correspond to the platform on which you are compiling gvSIG.
A small configuration is needed to indicate the platform details to Maven, so that it can load the corresponding native libraries when compiling gvSIG. To do this, create a file .gvsig.platform.properties in your user's home directory with the following contents:
native_platform=linux
native_distribution=all
native_compiler=gcc4
native_arch=i386
native_libraryType=dynamic
export native_classifier=${native_platform}-${native_distribution}-${native_compiler}-${native_arch}-${native_libraryType}
The first 5 values are the important ones; their meaning is explained in the section on compiling native libraries.
The currently supported values, i.e. for which the native libraries are already compiled and available, are:
| platform | distribution | compiler | arch | libraryType | Comentarios |
| linux | all | gcc4 | i386 | dynamic | Versión de 32 bits (equivalente en general a una Ubuntu-10.04) |
| win | nt | vs8 | i386 | dynamic | Versión de 32 bits, compatible con windows XP, Vista y 7. |
| mac | 10.5 | gcc4 | universal | dynamic | Plataforma todavía no disponible. Está en proceso de preparación y pueden variar alguno de los parámetros de la plataforma. |
This configuration allows us to work directly with the configuration of the project that has been prepared to integrate Maven with Eclipse for gvSIG. If we invoke Maven from the command line, we will need to introduce these parameters to Maven in a different way. There are two options:
Include the native-classifier and the native-platform variables values each time you invoke Maven. Example:
mvn -Dnative-classifier=linux-all-gcc4-i386-dynamic -Dnative-platform=linux install
Define an environment variable MAVEN_OPTS that includes the native_classifier variable. In Linux, for example, it would be enough to include the following in the .bash_rc file:
if [ -f "${HOME}/.gvsig.platform.properties" ]
then
. ${HOME}/.gvsig.platform.properties
export MAVEN_OPTS="-Xmx256M -XX:MaxPermSize=64m -Dnative-classifier=${native_classifier} -Dnative-platform=${native_platform}"
else
export MAVEN_OPTS="-Xmx256M -XX:MaxPermSize=64m"
fi
With this we can directly pass the platform values to Maven from Eclipse and to Maven from the console. For other operating systems you can pass the value directly to the native_classifier in the definition of the environment variable, but if you change the platform value, you must remember to change it for both cases (from Eclipse and from the console).
In addition to the platforms for which compiled native libraries are available, you can compile them by following the steps indicated in the document compilation of native libraries, and configure the parameters of the .gvsig.platform.properties file or the corresponding environment variable.
Those who are responsible for publishing binaries, source code or gvSIG project documentation will need to configure Maven to have write access to the server which hosts the gvSIG Maven repository through SCP (SSH).
To do this you must configure the Maven settings.xml file with the necessary information to access the Maven repository of gvSIG. This file is located in the USER_HOME/.m2 /, where USER_HOME is the user's home directory, which depends on the operating system that you are using.
If this is the first time you use Maven 2, you will need to create this folder as well as the settings.xml file manually.
The file needs an entry to configure the access to the gvSIG server, which is indicated with its ID gvsig-repository. Since the access is through SSH, we need to include the username and password:
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<servers>
<server>
<id>gvsig-repository</id>
<username>[USUARIO]</username>
<password>[CLAVE]</password>
<filePermissions>666</filePermissions>
<directoryPermissions>777</directoryPermissions>
</server>
</servers>
</settings>
Note
It is important to include the permission settings as indicated in the example above, because with every file that is uploaded, the user and group that uploaded it is specified to prevent other users from uploading modifications to the same file. In any case, a script on the OSOR server will update the file permissions on a daily basis.
If you do not want to show the password in the previous file, Maven can encrypt passwords from the latest versions onwards. To do this, follow the steps described in the Maven documentation on Password Encryption
To summarize, the steps are:
Create a master password to encrypt the server passwords with this command:
mvn --encrypt-master-password <clave-maestra>
This will return the encrypted password, something like:
{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}
Keep the master password in the file [USER HOME]/.m2/settings-security.xml (create the file if it doesn?t exist yet) with the following content:
<settingsSecurity> <master>[CLAVE MAESTRA ENCRIPTADA]</master> </settingsSecurity>
Using the example from the previous step, it would be something like this:
<settingsSecurity>
<master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master>
</settingsSecurity>
Encrypt the password to access the OSOR server:
mvn --encrypt-password <clave>
Which will return something like:
{COQLCE6DU6GtcS5P=}
Substitute the open password with the encrypted password in the [USER HOME]/.m2/settings.xml file:
<server> <id>gvsig-repository</id> <username>[USUARIO]</username> <password>[CLAVE ENCRIPTADA]</password> </server>
Following the previous example, it would result in something like this:
<server>
<id>gvsig-repository</id>
<username>USER</username>
<password>{COQLCE6DU6GtcS5P=}</password>
</server>
The steps for creating an Eclipse workspace for working with gvSIG are as follows:
Start Eclipse and create a new workspace for gvSIG 2.0.
Set the encoding used in gvSIG (ISO-8859-1):
Window > Preferences: General > Workspace > Text file encoding = ISO-8859-1
Set compatibility with Java 1.5 / 5.0 for all the projects (those which are compatible with Java ME CDC also have compatibility with Java 1.4):
Window > Preferences > Java > Compiler > Compiler Compliance Level = 1.5 (or 5.0).
In Eclipse, register the subversion repository in which we will be working.
It is possible to access to the subversion repository in two different ways:
The access URL is: https://devel.gvsig.org/svn/gvsig-desktop.
Because a default installation of Eclipse does not provide support for subversion, it is necessary to install plugins for doing so:
Note
It is important to take note of the subversion plugin's version or configuration, and to ensure that is the same version as the subversion client in all cases: command line, Eclipse, etc. This is because with each new version of subversion the local format of the information changes, and backward compatibility is not maintained.
In other words, if a subversion 1.6 client is used for doing a checkout or an update, an older version (1.5. 1.4, etc.) will not work correctly if it is used subsequently.
If internet access is through a proxy, this must first be configured in Eclipse. To do this select the option:
Window > Preferences > General > Network Connection
Proxy access to the network can be configured in the preferences window. It is possible to choose either System proxy configuration or to specify a Manual proxy configuration and then manually set the connection values.
To register the choosen subversion repository, open exploring perspective of the subversion repository. If it is not available, it can be accessed from:
Window > Open Perspective > Other : SVN Respository Exploring
Once the perspective has been opened, it is possible to add the gvSIG repository from the SVN repositories view.
From this point onwards project locations within the gvSIG subversion repository will be referred to. The repository has the usual subversion structure:
From here on, the subversion paths will show [Repository]/[VERSION] rather than indicating the repository, and if trunk, tags/v2_0_0_Build_2007, etc. Keep in mind that at the time of writing, version 2.0 is being developed in branches/v2_0_0_prep branch, which is where projects can currently be downloaded, even though they will in future be moved to the trunk.
Download the build project.
To do this, one must apply a checkout from the source repository. From the SVN Repository view, navigate to:
[VERSION] (ej: branches/v2_0_0_prep)
Select the build folder and apply a checkout by clicking on the left button on the folder and selecting the appropriate option. In the checkout dialog, accept the default options and click Finish.
Once finished, the project will be available in the Java or Resource perspective.
Alternatively, the following command can be executed from the console:
svn co https://devel.gvsig.org/svn/gvsig-desktop/branches/v2_0_0_prep/build
As with Eclipse, if internet access is through a proxy, the subversion client must be configured to connect to the server through the proxy. The configuration instructions are available in the FAQ of the official subversion web, or in the section on configuration of servers in the subversion book.
Once the build project has been downloaded from the console, it can be imported into Eclipse.
Open the Ant view by selecting the following menu option:
Window > Show view > ant
Install the basic configuration of Maven for gvSIG.
The build project contains the basic Maven configuration for all the gvSIG projects in a general pom.xml, as well as specific configurations for each project type:
Initially, and each time that any of these files are changed, these files must be installed in the local repository of Maven. There are two ways of doing this:
Eclipse: Add the build.xml file in the build project to the open Ant view. A number of Ant objectives will appear, amongst which is mvn-install. This is launched by double clicking or by selecting the required objective and clicking the icon.
Console: from the build folder, launch:
mvn install
Configure Eclipse to correctly load the projects generated from Maven.
To do this, from the Ant view invoke the objective: mvn-configure-eclipse-workspace. This will automatically create an environment variable in Eclipse, which is used to refer to the jars of the dependences managed through Maven. It will ask for the location of the workspace, which usually will be the default.
Alternately, from the console it is possible to use Maven as follows:
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo
Then close Eclipse and open it again.
Check that the M2_REPO variable is correctly defined in Eclipse. From the menu select:
Window > Preferences : Java > Build Path > Classpath Variables
The variable value must be something like (replace [USER_HOME] for the user's folder, according to the Operating System):
M2_REPO = [USER_HOME]/.m2/repository
To the Ant view add the build.xml file from the group of projects that you are going to work on. Groups of Projects will be explained in detail at a later stage but for now think of them as lists of projects (libraries and extensions) which are in the build/projects folder.
If the intention is to download the projects of a complete gvSIG, add the following file to the Ant view:
build/projects/gvsig-standard/build.xml
Start downloading the projects.
To do this, from the Ant view invoke the objective: svn.checkout.all. A form opens where it is possible to select:
Alternatively, it is possible to invoke this Ant objective from the console, or to do a checkout of each project, from Eclipse or from the console. In the latter case, it will be also be necessary to generate the Eclipse project configuration.
Import the projects into Eclipse. Once the previous step is complete the projects can be imported into Eclipse by choosing the following menu option:
File > Import > General > Existing projects into workspace
Click on Select root directory and select the workspace directory. The list showing the projects to import will appear and, after accepting them, Eclipse will proceed to compile the imported projects.
Note
when importing the projects, check that the option Copy projects into workspace is deactivated, because the intention is to use the same projects which have been downloaded directly.
The eclipse plugin for maven does not link eclipse projects between them until they are already imported into the eclipse workspace, so we must regenerate the projects eclipse configuration.
From the Ant view, select the mvn-eclipse-eclipse goal. Once the process has finished, select all projects and refresh them (F5 o press the right button and select the Refresh option).
Finally, the eclipse plugin for maven generates the eclipse plugin configuration only for the java projects, that is, the projects which have java code. As there are some multimodule projects, only the eclipse project configuration of the submodule final children will be generated. As an example, the org.gvsig.annotation project has the following structure:
org.gvsig.annotation ??? org.gvsig.annotation.lib ? ??? org.gvsig.annotation.lib.api ? ??? org.gvsig.annotation.lib.impl ??? org.gvsig.annotation.main ???? org.gvsig.annotation.swing ??? org.gvsig.annotation.swing.api ??? org.gvsig.annotation.swing.impl
If we look at the current imported projects, we will find only the following ones:
We need to have, at least, each root parent project to be able to update everything when synchronizing from subversion, as well as allowing us to perform actions to all the submodules of the same project.
There is only one way that we are aware of to be able to import those root parent projects:
Select the eclipse menu: File > New > Project....
In the dialog, select the option: General > Project and click Next
In the following dialog, fill in the following form fields:
Finally click Finish and the project will be available in eclipse. Its not a java project, so we must not edit java files from it, but through the subprojects. Those root projects will be used only to perform maven actions to all the submodules or to synchronize from subversion.
Those are the projects to import that way:
Note
This final step is certainly cumbersome, but we haven't found a more authomatic way to perform it. We had already tried to commit to subversion the .project files of those root projects but then, in the initial eclipse import of all the gvSIG projects, only the root projects are included. You had to import then each child submodule one by one, which is still worse. The maven plugin for eclipse could be used to solve that problem, but is has other problems still to be solved.
En el momento de preparar esta guía, Eclipse no lleva soporte de forma oficial para maven. Existen algunos plugins disponibles que permiten integrar maven en eclipse, aunque parece que todavía no son completamente funcionales. Uno de ellos (Q4E), de hecho, está en proceso de ser incorporado a eclipse de forma oficial, bajo el nombre Eclipse IAM, pero todavía no ha sido liberado.
Por no ligarnos a un plugin no oficial de eclipse, por ahora se va a emplear una integración básica de eclipse con maven, que permita en cierta forma compartir la configuración de proyecto de maven con eclipse, así como invocar a maven desde el propio eclipse.
Note
si nos hemos descargado el workspace siguiendo las instrucciones del documento Cómo montar un workspace con Eclipse (ver documentos relacionados), ya tendremos el workspace preparado.
Para que el eclipse sea capaz de encontrar el repositorio de maven es necesario configurar la variable en el workspace. Esto lo podemos hacer de forma sencilla empleando el plugin eclipse de maven, con el objetivo:
mvn configure eclipse workspace
Al hacerlo desde eclipse, ya tomará por defecto el valor del path del workspace sobre el que estamos trabajando.
Si queremos lanzarlo desde consola, la instrucción es:
mvn eclipse:add-maven-repo -Declipse.workspace=WORKSPACE_PATH
En 'WORKSPACE_PATH' especificaremos la ruta absoluta al workspace.
Note
los proyectos generados desde eclipse con los objetivos create library y create extension ya generan también automáticamente el proyecto de eclipse.
Si tenemos un proyecto configurado con maven, no es necesario crear manualmente el proyecto de eclipse, ya que maven puede generarlo por nosotros. Para ello bastará con usar el siguiente objetivo:
mvn eclipse
Desde consola, la instrucción equivalente es:
mvn -P eclipse-project
Note
La forma habitual de generar un proyecto de eclipse desde maven es emplear la instrucción mvn eclipse:eclipse. Sin embargo, para algunos proyectos, como los que generan varios jars en los que se incluyen clases de tipo Library, el plugin de maven que genera los proyectos de eclipse no es capaz de generar toda la configuración necesaria, por lo que se ha creado un perfil desde el que se invoca al plugin de eclipse y, además, añade el resto de configuración necesaria. Si en algún caso se creara el proyecto de eclipse sin usar el perfil eclipse-project, el único problema es que los tests unitarios que empleen el mecanismo de inicialización automática de librerías no funcionaran si los lanzamos desde eclipse.
Esto generará los archivos de eclipse necesarios, que nos permitirán importar el proyecto desde eclipse, con todas las dependencias, directorios de fuentes, etc. ya definidos.
Si ya existe el proyecto de eclipse, el objetivo anterior no lo sobreescribe, para ello tenemos que emplear antes el objetivo:
mvn eclipse clean
O desde consola:
mvn eclipse:clean
En los proyectos de gvSIG, está configurado de forma que, además de descargar y enlazar las dependencias binarias (jars con clases) en el proyecto de eclipse, maven intentará descargar también los jars con los fuentes y los javadocs correspondientes, enlazándolos a cada jar de binarios. Esto nos permitirá ver fácilmente la documentación y el código fuente de las dependencias de nuestros proyectos.
Por otro lado, si generamos los proyectos de eclipse para un grupo de proyectos, maven nos enlazará las dependencias entre los proyectos del grupo a nivel de proyecto, en vez de a nivel de archivo jar.
Esto permite que los proyectos de eclipse no se suban al repositorio de fuentes de gvSIG, ya que se pueden generar fácilmente para un proyecto o conjunto de proyectos.
Para facilitar el uso de maven desde eclipse, se han preparado una serie de lanzadores con los objetivos más usados en los proyectos con maven.
Dichos lanzadores están definidos dentro del proyecto build, por lo que una vez incluido este proyecto en nuestro workspace de eclipse, los tendremos disponibles automáticamente.
Para lanzar cualquiera de ellos deberemos tener abierto el proyecto sobre el que queremos trabajar, y seleccionar el lanzador correspondiente desde la opción de Herramientas externas (External Tools).
Eclipse no detecta una dependencia en el repositorio de maven, aunque el jar correspondiente sí que existe en disco
Por alguna razón, parece que Eclipse no se da cuenta de cambios en librerías de dependencias que están puestas a través de una variable de entorno. Incluso refrescando y recompilando el proyecto a veces no detecta el jar correspondiente.
Una forma que suele funcionar consiste en:
| platform | distribution | compiler | arch | libraryType | Comentarios |
| linux | all | gcc4 | i386 | dynamic | Versión de 32 bits (equivalente en general a una Ubuntu-10.04) |
| win | nt | vs8 | i386 | dynamic | Versión de 32 bits, compatible con windows XP, Vista y 7. |
| mac | 10.5 | gcc4 | universal | dynamic | Plataforma todavía no disponible. Está en proceso de preparación y pueden variar alguno de los parámetros de la plataforma. |
Maven permite trabajar con lo que llama multimódulos o una estructura multiproyecto. Esto nos permite lanzar una orden de maven sobre un grupo o jerarquía de proyectos, desde una única llamada a éste. Para ello tenemos un pom.xml que hace referencia a un conjunto de proyectos de maven.
La estructura habitual consiste en tener una organización en árbol de proyectos, pero también podemos tener una estructura plana, en el que el proyecto que contiene el pom.xml en el que se hace referencia al resto de proyectos se encuentra a la misma altura que estos.
En gvSIG la estructura de proyectos que hay en el repositorio de fuentes no está pensada para ser descargada tal cuál, sino que se debe descargar proyecto a proyecto, con lo que tenemos una lista de proyectos todos dentro del mismo directorio.
Aunque en un futuro se podría migrar a una estructura multimódulo de proyectos, por ahora la vamos a simular mediante grupos de proyectos dentro del directorio build de gvSIG. Dentro de este, en el subdirectorio projects se han creado una serie de directorios, cada uno de los cuáles hace referencia a un grupo de proyectos:
build `-projects |-gvsig-base |-gvsig-cdc-compat |-gvsig-coverage |-gvsig-coverage-base ...
Si accedemos a uno de estos directorios, vemos que contienen un archivo pom.xml, el cuál hace referencia a un conjunto concreto de proyectos. Así, si desde aquí usamos maven, la orden se lanzará automáticamente para cada uno de los proyectos referenciados.
Este mecanismo nos permite, de forma cómoda, realizar operaciones de compilación e instalación sobre un conjunto de proyectos, o incluso generar un build de gvSIG completo.
El criterio para definir los grupos ha sido el de unir proyectos sobre una misma funcionalidad o cuyo desarrollo se realice de forma conjunta. Además, aprovechando que un pom.xml puede hacer referencia, tanto a proyectos sueltos, como a otros conjuntos de proyectos, se ha definido un grupo para la generación de un build completo con la unión de otros grupos.
Por ejemplo, si estamos desarrollando sobre GPE, actualmente está dividido en los siguientes proyectos:
Si queremos compilarlos todos a la vez, bastará con ir al directorio gvsig-gpe y realizar la orden:
mvn compile
Esto realizará la compilación de los distintos proyectos de GPE, uno tras otro. Si, en alguno de ellos, se produce un error de compilación, el proceso se detendrá y no seguirá en los siguientes.
Dentro de cada uno de estos directorios de grupos de proyectos, tenemos también un script de utilidad que nos permite hacer un checkout de forma rápida de los proyectos del grupo. Por ejemplo, si queremos desarrollar sobre GPE, bastará con hacer un checkout inicial del directorio build y, a continuación, desde el subdirectorio projects/gvsig-gpe llamar al script svnco.sh, que se encargará de hacer un checkout de los proyectos de GPE.
Aprovechando el mecanismo anterior de los grupos de proyectos, se han definido dos grupos que permiten trabajar con todos los proyectos de un build de gvSIG:
A partir de ahora consideraremos que vamos a trabajar con la versión del build estándar.
Para compilar todo gvSIG usaremos maven, bien desde eclipse, bien desde consola. La forma habitual será mediante el objetivo install:
Eclipse: si no lo tenemos aún, añadiremos a la vista de Ant el archivo build/projects/gvsig-standard/build.xml y lanzaremos el objetivo mvn-install. De la misma forma, tenemos otros objetivos de uso habitual accesibles con este mecanismo, con su equivalencia en maven, como por ejemplo:
Al menos la primera vez deberían compilarse y lanzarse los tests unitarios en los proyectos que los tengan activados. El resto de veces, se puede hacer la compilación sin lanzarlos mediante el objetivo mvn-install-without-tests.
Consola:
mvn install
Esto compilará todos los proyectos e instalará todas las extensiones y sus archivos en la ubicación correspondiente.
Los builds de gvSIG desde maven están configurados para ser generados en el directorio build/product, en vez de dentro del proyecto de _fwAndami como se hacía con ant.
Podemos lanzar gvSIG de dos formas distintas:
Eclipse: automáticamente, al haber incluido el proyecto build se nos habrán configurado una serie de configuraciones de arranque de utilidad. Para arrancar gvSIG seleccionaremos:
Run > Run Configurations > Java Application
De la lista de configuraciones, tendremos al menos las siguientes 3:
Seleccionaremos la que corresponda a nuestro sistema operativo. Esta configuración la podemos usar, tanto para ejecución normal, como para ejecución de gvSIG en depuración.
Estos launchers están configurados incluyendo en su classpath la lista the archivos .jar disponibles en la carpeta build/product/lib de forma individual, los cuáles se corresponden con el propio jar the andami más todas sus dependencias. Dado que dichos archivos se generan y copian a través de maven, algunas veces eclipse no se da cuenta de los cambios en dicha carpeta.
Algo que pasa algunas veces es que eclipse cree que no hay nada en la carpeta build/product/lib, y sin embargo sí que están los archivos. Entonces, al usar uno de los launchers eclipse nos da un error, algo como:
The archive: /build/product/lib/castor-0.9.5.3.jar which is referenced by the classpath, does not exist
Para solventarlo bastará con ir a la carpeta build/product/lib con el package explorer, project explorer o navigator de eclipse y refrescarlo. Entonces ya aparecerán los archivos jar necesarios y podremos lanzar el launcher de nuevo.
Consola: dentro del directorio build/product tenemos ya un gvSIG.sh, o un gvSIG.bat según corresponda, para arrancar el build de gvSIG que hayamos generado.
Algunas de las extensiones de gvSIG, necesitan el uso de librerías nativas para su funcionamiento. El problema existente con este tipo de librerías es que es necesario tenerlas compiladas para cada plataforma y sistema donde se quiera hacer uso de gvSIG.
Para facilitar la distribución y construcción de estas librerías se ha integrado con el actual sistema de construcción basado en maven. Para ello se ha añadido funcionalidad a las fases de construcción. Es necesario entender que cuando se trabaja con librerías nativas existen tres partes claramente diferenciadas:
Un desarrollador java que trabaje sobre una plataforma para la cual existan librerías nativas ya compiladas no tendrá que preocuparse de hacer nada especial para el uso de estas. Estas nativas aparecen como dependencias de otras librerías java y serán descargadas a $HOME/.m2 cuando hagamos un mvn install del proyecto java que las incluya. Posteriormente, cuando se hace un mvn install -Pinstall-extensions de la extensión que hace uso de las librerías java, los binarios nativos de los cuales se dependa serán instalados en el directorio .depman de nuestro ?home?.
Actualmente para que se reconozca la plataforma en la que estamos se ha de indicar explícitamente.
El proyecto org.gvsig.maven.base contiene un directorio org.gvsig.maven.base.pom con un fichero pom.xml donde podemos cambiar la plataforma, distribución, compilador y arquitectura sobre la que estamos funcionando en caso de que no nos vaya bien la que viene por defecto. Una vez hecho esto deberemos ir al raiz del proyecto y ejecutar mvn install para instalar los cambios en nuestro repositorio local.
Este proyecto puede descargarse de: https://svn.forge.osor.eu/svn/gvsig-tools
Con esta pequeña introducción a la problemática de las librerías nativas a continuación se explica cómo compilar las librerías que actualmente se encuentras migradas a maven.
Para cada sistema, ya no sólo es necesario tener instalado el JDK y por supuesto maven (aunque se puede hacer uso del maven que se distribuyen dentro del directorio build). Es necesario descargarse los programas necesarios para compilar en cada sistema.
Para todos los sistemas es necesario descargarse e instalar CMake: http://www.cmake.org.
Es necesario tener un workspace al menos con los siguientes proyectos:
Compilar Java: Es tan sencillo como lanzar la instrucción del directorio de la librería ( o el target ant asociado ). Automáticamente se descargará la librería JNI de la que depende y las librerías externas de las que depende desde el repositorio de maven:
Linux: mvn install -Dnative-distribution="all" Windows y Mac: mvn install
Compilar Java + JNI: Al igual que antes se compilará la parte Java y en este caso se compilará también la parte JNI, las dependencias externas se descargarán desde el repositorio de maven:
Linux: mvn install -Dnative-distribution="all" -Pjni-devel Windows y Mac: mvn install -Pjni-devel
Las librerías nativas necesitan siempre del parámetro -Dnative-distribution={mi distribución linux}. La razón por la que es necesario es que según que distribución para la que se haya compilado puede que requiera unas dependencias externas u otras, o incluso pueden ocurrir problemas de compatibilidad binaria con las librerías del sistema.
Si una distribución linux no está soportada o no se han subido al repositorio de maven las dependencias, entonces fallará la búsqueda de dependencias y dará un error, es por tanto responsabilidad de los mantenedores de las librerías subir esas dependencias para las distribuciones oficiales de gvSIG.
En Windows, se considera que el compilador por defecto es el Visual Studio 2005 (vs8), por tanto para poder lanzar la compilación es necesario abrir una Consola de Visual Studio 2005" para que se definan correctamente las variables de entorno del compilador.
Aunque el sistema se lanza y se maneja con Maven, internamente hace uso de CMake, una herramienta multiplataforma que permite la compilación y generación de proyectos de compilación.
Para poder subir ficheros al repositorio hay que tener configurado el fichero settings.xml de nuestro repositorio local ($HOME/.m2) con los valores correctos para el servidor. Un ejemplo de este fichero podría ser el siguiente:
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0"
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<servers>
<server>
<id>gvsig-repository</id>
<username>nbrodin</username>
<password></password>
</server>
</servers>
</settings>
Desde una consola del sistema debemos tener definida la variable JAVA_HOME. Para ello escribimos:
export JAVA_HOME=$javasdk
donde $javasdk es nuestra ruta local al JSDK de java. Actualmente la versión utilizada es la 1.6.0
La instrucción de compilación desde dentro del proyecto libjni-xxxx es la siguiente:
mvn install -Dnative-arch=$arch -Dnative-distribution=$distri -Pjni-devel -Dmaven.test.skip
donde $arch puede tomar los valores ?X86_64?, ?i386?, ?universal? y $distri puede ser ?nt?, "all", ?Ubuntu-9.10?, ?10.5?, etc...
El flag -Pjni-devel forzará a compilar el código nativo.
Si el proceso se completa con éxito se generará:
Los jar, tar.gz y fuentes se instalarán en el repositorio local de maven (.m2). Cuando estas dependencias sean necesitadas por una librería o extensión de gvSIG serán copiadas desde ahí.
El nombre del jar tendrá la forma siguiente:
?Estructura de paquete?-?versión?.extensión
Ej: org.gvsig.jgdal-2.0.jar
El nombre de los fuentes será:
?Estructura de paquete?-?versión?-sources.extensión
Ej: org.gvsig.jgdal-2.0-sources.jar
El de los javadoc:
?Estructura de paquete?-?versión?-javadoc.extensión
Ej: org.gvsig.jgdal-2.0-javadoc.jar
Y el de los binarios:
?Estructura de paquete?-?versión?-?operativo?-?distribución?-?compilador?-?plataforma?-dynamic/static.tar.gz
Ej: org.gvsig.jgdal-2.0-linux-all-gcc4-i386-dynamic.tar.gz
Las dependencias en tiempo de compilación con librerías del sistema se resolverán automáticamente si estas están debidamente instaladas. Por ejemplo para linux la compilación de jgdal necesita de la librería gdal instalada y se usará la del repositorio oficial de la distribución que usemos.
Para subir la versión que hemos compilado al repositorio habrá que hacer "deploy" del proyecto usando la siguiente instrucción:
mvn deploy -Dnative-arch=$arch -Dnative-distribution=$distri -Pjni-devel -Dmaven.test.skip
Los parámetros serán los mismos que usamos para hacer "mvn install"
Para compilar un proyecto nativo desde una consola en windows deberemos asegurarnos primero de que está definida la ruta al jdk de java en la variable PATH y que la variable JAVA_HOME también está definida.
Al abrir una consola de windows deberemos cargar el entorno de Microsoft Visual Studio. Para eso, habrá que ejecutar desde la consola el fichero llamado vcvars.bat, que está en el directorio bin de VC. La ruta más común para este fichero suele ser:
?C:Archivos de programaMicrosoft Visual Studio 8VCbin?
La compilación se hará con el comando:
mvn install -Pjni-devel -Dmaven.test.skip
Para subir la versión que hemos compilado al repositorio habrá que hacer "deploy" del proyecto usando la siguiente instrucción:
mvn deploy -Pjni-devel -Dmaven.test.skip
Los parámetros serán los mismos que usamos para hacer "mvn install"
La dependencias nativas (proyectos libjni-xxxx) son compiladas e instaladas en el repositorio local de maven ($HOME/.m2) usando ?mvn install?, pero no son instaladas para ejecución a no ser que lo invoquemos explícitamente. Las dependencias nativas que se usan en la ejecución estarán en el directorio $HOME/.depman. En caso de linux el directorio lib contendrá las librerías y en caso de windows será el directorio bin. Para que esto suceda se ejecutará la instrucción:
mvn install -Pinstall-extension -Dmaven.test.skip
Esta instrucción se ejecutará dentro de la extensión que tenga dependencias con las librerías nativas, aunque sea de forma indirecta. Hay que tener en cuenta que las extensiones tienen un directorio distribution con un fichero distribution.xml con la información para regenerar las dependencias de las distribución en ejecución.
Las librerías que no están instaladas en el sistema necesitan ser resueltas para compilar. Para ello es necesario disponer del SDK de estas dependencias. El SDK de una dependencia contiene:
El sdk estará empaquetado un tar.gz y el nombre tendrá la siguiente estructura:
?nombre de librería?-?version?-?operativo?-?distribución?-?compilador?-?plataforma?-dynamic/static.tar.gz
Ej: gdal-1.7.1-win-nt-vs8-i386-dynamic.tar.gz
A la hora de compilar una librería nativa es necesario que las dependencias estén instaladas en el directorio $HOME/.depman. Cuando se hace un maven install cogerá el tar.gz con el SDK del cual se depende y que está en el repositorio local (.m2) y lo descomprimirá en $HOME/.depman. En caso de que no esté instalado en el repositorio local se lo descargará del repositorio remoto. Este proceso se realizará de forma automática.
Cuando creamos un SDK del cual depende una librería nativa tendremos que subirlo al repositorio una vez montada la estructura que hemos definido en el apartado anterior. Para esto tendremos que empaquetar manualmente los ficheros en un tar.gz.
Una vez tenemos el paquete hecho habrá que subirlo al repositorio usando maven. La instrucción que debemos usar es similar a la siguiente:
mvn deploy:deploy-file -Dfile=?C:\gdal-1.7\gdal-1.7.1-win-nt-vs8-i386-dynamic.tar.gz? -Durl=scp://shell.forge.osor.eu/home/groups/gvsig-desktop/www/downloads/pub/projects/gvSIG-desktop/maven-repository -DrepositoryId=gvsig-repository -DgroupId=org.gdal -Dversion=1.7.1 -DartifactId=gdal -Dpackaging=tar.gz -Dclassifier=win-nt-vs8-i386-dynamic
En este caso se muestran valores de ejemplo para subir el SDK de gdal en su versión 1.7.1 en un windows de 32 bits con compilación con Visual Studio 8. Habría que sustituir estos valores por los correctos para nuestro caso.
El parámetro -DrepositoryId contiene una etiqueta que corresponde con el identificador que debe haber dentro del fichero settings.xml de nuestro directorio .m2. De esta forma podrá conectarse al repositorio por scp validando previamente la cuenta.
Es bastante común hacer uso de dependencias dentro de un proyecto tan grande como es gvSIG. Maven nos ayuda en la tarea de definir esas dependencias. En este apartado se explica como hacer que tu proyecto Java tenga como dependencia una librería nativa.
Únicamente es necesario modificar la sección <dependencies> de tu proyecto Java:
<dependency>
<groupId>org.gvsig</groupId>
<artifactId>org.gvsig.jgdal</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.gvsig</groupId>
<artifactId>org.gvsig.jgdal</artifactId>
<version>2.0</version>
<classifier>${native-classifier}</classifier>
<type>tar.gz</type>
</dependency>
El ejemplo anterior lo que nos muestra es que se depende de la librería org.gvsig.jgdal, la primera parte se refiere a la parte Java de jgdal (los .jar), y la segunda parte se refiere a la parte nativa, es decir el conjunto de binarios dependientes de plataforma.
El elemento <classifier> de un pom, permite añadir un clasificador a cualquier artefacto maven, de manera que nos permite hacer un tratamiento especial. En el caso de las librerías nativas, el clasificador se ha utilizado para añadir la plataforma, arquitectura, distribución, sistema operativo y tipo de dependencia.
La propiedad ${native-clasifier} se genera a partir de otras propiedades, a continuación se muestra para cada sistema operativo soportado el valor que toma:
Linux:
<native-platform>linux</native-platform> <native-distribution>all</native-distribution> <native-compiler>gcc4</native-compiler> <native-arch>i386</native-arch> <native-libraryType>dynamic</native-libraryType>
Windows:
<native-platform>win</native-platform> <native-distribution>nt</native-distribution> <native-compiler>vs8</native-compiler> <native-arch>i386</native-arch> <native-libraryType>dynamic</native-libraryType>
MacOSX:
<native-platform>mac</native-platform> <native-distribution>10.5</native-distribution> <native-compiler>gcc4</native-compiler> <native-arch>universal</native-arch> <native-libraryType>dynamic</native-libraryType>
La propiedad se genera de la siguiente forma:
<native-classifier>
${native-platform}-
${native-distribution}-
${native-compiler}-
${native-arch}-
${native-libraryType}
</native-classifier>
Por tanto es fácil cambiar cualquier valor desde la línea de comandos haciendo uso de -Dnative-distribution="valor que quiero que tenga".
Otro elemento que no es habitual en las dependencias de tipo jar, es el elemento <type/>. En este caso, se está usando para que la extensión de la dependencia que busque sea de tipo tar.gz, ya que en este caso al no ser un único fichero, si no un conjunto de binarios o incluso de ficheros necesarios para la compilación de librerías nativas, estos se empaquetan y comprimen en un archivo contenedor (tar.gz).
Al igual que maven tiene un repositorio local donde se descargan los jars de los que se depende, se ha creado un repositorio local donde se descomprimen los binarios nativos:
${user.home}/.depman
Donde en cada sistema operativo toma el valor adecuado. Los proyectos al descomprimirse generan una estructura de directorios similar al de un SDK de librerías nativas multiplataforma:
${user.home}/.depman/
|-include
-- Cabeceras de archivos para C/C++
|-lib
-- Nativos en linux/mac (.so/.dylib) o
librerías de enlace en windows (.lib).
|-bin
-- Nativos en Windows (.dll).
|-Frameworks
-- Nativos en Mac (.framework)
Maven cuándo se descarga una dependencia nativa de tipo tar.gz, automáticamente la deposita en el repositorio de maven (${user.home}/.m2) sin descomprimir y a continuación la descomprime en el directorio ${user.home}/.depman. Además ese directorio se añade a los PATHS de ejecución de los Tests unitarios de librerías y proyectos Java, para que si requieren de la librería nativa no existan problemas de ejecución.
En este apartado se plantean las bases para la creación o migración de nuevas librerías nativas dentro de gvSIG. Primero se explica la estructura que deben seguir los proyectos para su correcta compilación y generación. A continuación cómo integrar el proyecto en CMake y cómo se debe generar el pom.xml para que todo el sistema compile de manera integrada en el sistema de construcción de gvSIG además de resumir el ciclo de vida de una librería nativa dentro del sistema de construcción de maven.
Para llevar a cabo un proyecto de una librería nativa, se recomienda una estructura de directorios determinada que facilitará la construcción y organización del proyecto:
librería-jni/
|-src/
|-main/
| |-java
-- Ficheros .java
| |-native
-- Ficheros .cpp y de cabecera de C++
| |-resources
-- Ficheros de recursos a incluir en el .jar
|-test/
|-java
-- Tests unitarios
Seguir esta estructura es importante, tanto para proyectos de maven, como para la compilación de la parte nativa, ya que CMake seguirá esta estructura para buscar los archivos fuente y generar los binarios nativos.
Aunque maven es capaz de compilar y administrar dependencias de tipo jar, no es así con las librerías nativas. Existe algún plugin que es capaz de ello, pero no al nivel que se requiere en un proyecto tan grande como gvSIG. Por ello se hace uso de CMake, que es un sistema para la construcción de librerías nativas multiplataforma (no únicamente librerías JNI).
CMake se encarga de generar los ficheros de proyecto y de compilación para cada plataforma y en cada sistema operativo, permitiendo manejar de una forma centralizada varios sistemas e incluso compiladores. Por ejemplo para linux generará los ficheros Makefile necesarios y para Windows generará los ficheros NMakefile o las soluciones de Visual Studio que se tenga instalada en el sistema.
Para facilitar la tarea se han incorporado al directorio build una serie de Macros de CMake que simplifican los ficheros de proyecto.
Para integrar una librería JNI con CMake es necesario crear en el directorio raíz un fichero CMakeLists.txt que tendrá la siguiente estructura:
PROJECT(jgdal)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
SET(JGDAL_VERSION_MAJOR "2")
SET(JGDAL_VERSION_MINOR "0")
SET(JGDAL_VERSION_PATCH "0")
SET(VERSION "${JGDAL_VERSION_MAJOR}.${JGDAL_VERSION_MINOR}.${JGDAL_VERSION_PATCH}")
SET(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/../build/CMakeModules;${CMAKE_SOURCE_DIR}/CMakeModules;${CMAKE_MODULE_PATH}")
FIND_PACKAGE(DepMan REQUIRED)
INCLUDE(GeneralMacros)
CONFIGURE_DEFAULTS()
IF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
SET(CMAKE_INSTALL_PREFIX
${DEPMAN_PATH} CACHE PATH "depman path install prefix" FORCE
)
ENDIF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
FIND_PACKAGE(JNI REQUIRED)
FIND_PACKAGE(GDAL REQUIRED)
ADD_SUBDIRECTORY(src/main/native)
CONFIGURE_END()
El ejemplo anterior está basado en el de JGDAL y tiene varias instrucciones a tener en cuenta. La instrucción para la busqueda en el sistema de las librerías JNI necesarias para la compilación nativa es:
FIND_PACKAGE(JNI REQUIRED)
Para la búsqueda de otras dependencias que tu proyecto necesite se deberá hacer de una forma similar, por ejemplo en el caso de GDAL se hace:
FIND_PACKAGE(GDAL REQUIRED)
Aunque CMake incorpora una gran cantidad de scripts para la búsqueda de dependencias, si no tiene una, se pueden crear nuevas, como es el caso de GDAL, que se encuentra dentro del directorio CMakeModules ubicado en el directorio build.
Otra instrucción del script a tener en cuenta es la de:
ADD_SUBDIRECTORY(src/main/native)
Esta instrucción indica que se debe buscar archivos CMakeLists.txt en ese subdirectorio para configurar el resto de la compilación.
Hasta ahora sólo hemos configurado el entorno base de CMake, a continuación se muestra el script que debe ir dentro del directorio donde se encuentran los fuentes (.cpp,.c), para realizar la compilación del binario nativo:
SET(LIB_NAME jgdal)
FILE(GLOB SOURCES "*.c*")
include_directories(
${CMAKE_SOURCE_DIR}/include
${JAVA_INCLUDE_PATH}
${JAVA_INCLUDE_PATH2}
${GDAL_INCLUDE_DIR}
)
SET(LIBRARIES_OPTIMIZED
${GDAL_LIBRARY}
)
SET(LIBRARIES_DEBUG
${GDAL_LIBRARY}
)
SETUP_JNILIB(${LIB_NAME})
En este ejemplo, se están almacenando todos los ficheros .cpp y .c en la variable SOURCES y posteriormente se está configurando el entorno con los directorios de cabecera necesarios. Las variables JAVA_INCLUDE_PATH, JAVA_INCLUDE_PATH2 y GDAL_INCLUDE_DIR se definen al hacer uso de FIND_PACKAGE en el script principal, por lo que son accesibles para su uso en otros scripts. Luego se configuran las librerías de las que se depende, en este caso GDAL_LIBRARY. Finalmente se configura para que se cree una librería JNI.
Se recomienda que si se desea hacer un uso intensivo y avanzado de CMake se lea la documentación del mismo (http://www.cmake.org).
Para entender como se integra la construcción de librerías nativas en Maven es necesario entender como lleva a cabo la construcción maven, para ello primero exponemos lo que se denomina ciclo de vida de maven y a continuación mostraremos la configuración inicial.
Maven realiza ciertas fases denominadas ciclo de vida o lifecycle para llevar a cabo la compilación de los proyectos. En el caso de las librerías nativas, lo que se ha hecho es insertar ciertas acciones durante la ejecución de algunas de esas fases, aprovechando así el sistema de construcción que provee.
Los ciclos y lo que se realiza en cada uno de ellos se menciona a continuación:
El fichero de configuración pom.xml es similar a cualquier otro proyecto java, pero en este caso se configuran ciertos parámetros necesarios.
La cabecera se debe configurar de la siguiente manera:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.gvsig</groupId>
<artifactId>org.gvsig.jgdal</artifactId>
<packaging>jar</packaging>
<version>2.0</version>
<name>libjni-gdal Library</name>
<parent>
<groupId>org.gvsig</groupId>
<artifactId>gvsig-base-library-jni-pom</artifactId>
<version>2.0-SNAPSHOT</version>
</parent>
<properties>
<build-dir>${basedir}/../build</build-dir>
</properties>
...
No hay diferencia con otros proyectos, lo único a tener en cuenta es que la definición del elemento padre es: <artifactId>gvsig-base-library-jni-pom</artifactId>
El manejo de dependecias sigue siendo igual que en los proyectos java, aunque en las librerías nativas es habitual encontrarse que se depende de otras librerías nativas, por tanto se han de configurar correctamente, por ejemplo:
<dependencies>
<dependency>
<groupId>org.gdal</groupId>
<artifactId>gdal</artifactId>
<version>1.6.0</version>
<classifier>${native-classifier}</classifier>
<type>tar.gz</type>
</dependency>
</dependencies>
En algunos casos, nos podemos encontrar que una dependencia se pueda obtener por el sistema de paquetes del sistema (como es el caso de Ubuntu o Debian), por lo que no es necesario añadir la dependencia para ese sistema y sí para el resto, para ello se hace uso de los profiles de maven:
<profiles>
<profile>
<id>windows-profile</id>
<activation>
<property>
<name>native-platform</name>
<value>win</value>
</property>
</activation>
<properties>
<!-- This hack is necessary to allow correct search in windows -->
<build-dir>${basedir}\..\build</build-dir>
</properties>
<dependencies>
<dependency>
<groupId>org.gdal</groupId>
<artifactId>gdal</artifactId>
<version>1.6.0</version>
<classifier>${native-classifier}</classifier>
<type>tar.gz</type>
</dependency>
</dependencies>
</profile>
<profile>
<id>linux-profile</id>
<activation>
<property>
<name>native-platform</name>
<value>linux</value>
</property>
</activation>
</profile>
<profile>
<id>mac-profile</id>
<activation>
<property>
<name>native-platform</name>
<value>mac</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>org.gdal</groupId>
<artifactId>gdal</artifactId>
<version>1.6.0</version>
<classifier>${native-classifier}</classifier>
<type>tar.gz</type>
</dependency>
</dependencies>
</profile>
</profiles>
Con esta configuración y al incluir el pom padre específico para librerías jni, se incorporan a las fases del ciclo de vida la generación de los proyectos tipo makefile o NMakefile, la compilación, el empaquetado de los .tar.gz, la instalación en el repositorio de maven y por supuesto la instalación en el repositorio de librerías nativas ${user.home}/.depman y finalmente al hacer un deploy, el despliegue de esa dependencia.
cdc: compila un proyecto para Java ME CDC. Activa la compatibilidad con Java 1.4 y compila sobre el API de Java ME CDC. En algunos proyectos se emplea también para desactivar la compilación o generación de jars de partes no compatibles con Java ME CDC. Este perfil sólo se usa para el desarrollo en gvSIG Mobile. Ejemplo de uso:
mvn -P cdc install
Existen una serie de proyectos que mantienen compatibilidad, al menos a nivel de API, con Java ME CDC.
Para compilar (o cualquier otra acción) para Java ME CDC hay que activar un perfil de maven preparado para ello: cdc:
mvn -P cdc clean compile
Si se cambia entre compilación para Java SE y Java ME CDC, es recomendable limpiar la compilación para que no se empleen classes compiladas para el otro perfil, por eso se ha incluido la llamada al clean antes.
Se ha detectado que la versión del jdk 1.5 que se instala desde los repositorios en una Ubuntu de 64 bits (paquete sun-java5-bin) no instala el archivo javaws.jar, lo que provoca un error de dependencias al tratar de compilar el proyecto _fwAndami. Para solucionar esto hay que descargarse la versión del jdk 1.5 de 32 bits y copiar manualmente el jar al directorio correspondiente (${java.home}/lib/javaws.jar).
Este error también puede ocurrir si se está utilizando el OpenJDK, ya que parece ser que esta librería no está incluida. De momento gvSIG no soporta el OpenJDK, así que se puede copiar a mano la librería o bien usar el JVN de Sun.