The gvSIG developers guide aims to provide developers who will work with gvSIG all the information necessary to compile, edit and further develop gvSIG.

The main topics covered in the guide are:

• Maven: One of the major changes from versions prior to 2.0.0 is the use of Maven instead of Ant. Not only the compilation and construction of projects have changed with the switch to Maven, but also their structure.
• Create a project for gvSIG: how to create a new project, which may include libraries, extensions, etc, to develop with gvSIG.
• Working with a project: whether it is an existing project, or a project you just created, what will be the routine tasks to be performed during development.
• Generate installation files: what to do if we want our project to be installed on a binary gvSIG.
• Work with the core of gvSIG: it is preferable to work on a build or an installed version of gvSIG, but if we do not have one available, or if we need to change some core functionality, we can follow the steps in this section to prepare a work space and compile the gvSIG core.
• Coding and development standards defined by the gvSIG project.
• Migrate projects to gvSIG 2.0: For projects that worked on a previous gvSIG version and need to be migrated to 2.0, this section describes the main issues related to the migration.

Maven is a tool for the management and construction of software projects, especially for those based on Java. Maven has similar goals to make and ant, but with greater emphasis on the configuration by convention.

Maven is hosted by the Apache Software Foundation, and can be found at: http://maven.apache.org.

The main goals of Maven are:

• Facilitate the process of compilation and construction of the project.
• Generate quality documentation for the project.
• Provide development guidelines based on best practices.
• To facilitate seamless migration to new features of Maven.

Setting up a Maven project is done through the pom.xml file, which describes the main properties of the project and its dependencies with other modules and external components, as well as the Maven configuration to be applied. On the Maven website there is a reference guide on the pom.xml file format

Following the philosophy of configuration by convention, Maven defines a standard project structure:

project
|-- pom.xml
`-- src
    |-- main
    |   |-- java
    |   `-- resources
    |                   
    `-- test
        |-- java
        `-- resources

If we follow this structure (but if it is different, it can be configured) with a basic configuration, we can perform the typical tasks of any Java project, already predefined in Maven:

• Compilation of code.
• Packaging in .jar, .war or .ear files.
• Generation of javadoc and other reports.
• Implementation of unit tests.
• etc.

Each task is determined by a Maven objective, with its name passed as a parameter. Example:

mvn install

There are two main versions of Maven: 1.0 and 2.0. The latter version is used in gvSIG.

The functionality provided by Maven consists of a number of plugins that can be registered and configured for each project via the pom.xml.

The most commonly used plugins are registered and configured by default. If we use a different one for our project, or need to adapt the configuration of any existing ones, we can access the Maven plugins page.

For each plugin there is a user guide and documentation on the different parameters that are accepted by the plugin.

The Maven plugin page also provides links to other repositories of available plugins, mainly on codehaus.org and code.google.com.

Maven manages two types of dependency repositories:

<dependency>
    <groupId>org.gvsig</groupId>
        <artifactId>org.gvsig.tools</artifactId>
        <version>2.0-SNAPSHOT</version>
</dependency>

MAVEN_REPO/org/gvsig/org.gvsig.tools/2.0-SNAPSHOT/org.gvsig.tools-2.0-SNAPSHOT.jar

The Maven Getting Started Guide describes the common tasks, among which:

• Compile a project:

  mvn compile
  

• Generate the artifacts (usually .jar files) and install them in the local Maven repository so that they are available for the other projects. This in turn implies the compilation, generation of .jar files, launching of tests

  mvn install
  

• Upload a generated jar (or jars) to the Maven repository, to publish a binary for the other projects:

  mvn deploy
  

  This option will be used when we have finished a version of a project that we want to publish so that it is accessible for other developers.

• Delete everything that is generated with Maven, within the project:

  mvn clean
  

• Launch the unit tests:

  mvn test
  

  NOTE: Keep in mind that it is the virtual machine through which Maven is invoked that will launch the unit tests. This implies that, in general, we have the same requirements as gvSIG itself, such as having the JAI installed. This must be taken into account, also because the unit tests will be launched when generating a build.

To launch Maven in a project and generate jars without launching the unit tests, add the following parameter:

-Dmaven.test.skip=true

When offline, or when you want to disable the updating of SNAPSHOT dependencies, add the -o parameter.

Sometimes we may need to debug the unit tests of a project, launched by Maven.

To do this, there is a parameter that causes Maven to wait for a remote debug connection on port 5005, before launching each test:

mvn -Dmaven.surefire.debug test

More information can be found in the documentation of the Maven debugging tests plugin

It is possible that for some of the tasks Maven launches, such as the compilation of Java classes, or the generation of Javadoc, the default memory settings will not be enough.

If this happens, an OutOfMemoryError message will appear in the console. We can increase the maximum memory allocation of the JVM by defining the MAVEN_OPTS variable that allows us to pass parameters to the JVM that launches Maven. For example:

Linux:

export MAVEN_OPTS=-Xmx256M

Windows:

set MAVEN_OPTS=-Xmx256M

When there is not enough space for the loading of classes (PermGenSpace), this will produce an error like:

[INFO] Compilation failure
Failure executing javac, but could not parse the error:

The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: PermGen space
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:621)

In this case, we will need to increase the PermGen space with the -XX:MaxPermSize parameter. For example:

Linux:

export MAVEN_OPTS=-Xmx256M -XX:MaxPermSize=64m

Windows:

set MAVEN_OPTS=-Xmx256M -XX:MaxPermSize=64m

If you access the Internet through a proxy, you will need to configure Maven to download dependencies through this proxy, following the Configuring a proxy instructions at the Maven page.

Basically, this consists of including the corresponding configuration in the .m2/settings.xml file:

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

   ...

    <proxies>
        <proxy>
            <active>true</active>
            <protocol>http</protocol>
            <host>proxy.somewhere.com</host>
            <port>8080</port>
            <username>proxyuser</username>
            <password>somepassword</password>
            <nonProxyHosts>www.google.com|*.somewhere.com</nonProxyHosts>
        </proxy>
    </proxies>
</settings>

• The Maven project website: is the place where we can get the latest versions of Maven, general documentation and main plugins, etc.
• The dependency browser of the Maven project repository: this lets you search for artifacts from the Maven project repository that you may want to include as dependencies.
• The Codehaus plugin repository: the Mojo project of Codehaus develops additional plugins for Maven.
• The book Better Builds With Maven: the authors are some of the main developers of Maven, and we can download a free copy of the book after registration.
• Maven: The Definitive Guide: another book about Maven, available for reading online or as a PDF download under a Commons license.

When developing a project for gvSIG 2.0 we must consider several things if we want it to have the official endorsement of gvSIG and become part of the official gvSIG release.

• Maven must be used as the tool to build the project.

  Maven defines the group name, the groupId, and the identifier, the artifactId for the project. The groupID will be org.gvsig and the artifactId consists of the groupID followed by an identifier of the project.

  For example, when creating a topography plugin for gvSIG, all the project packages will start with org.gvsig.topography.

  The artifactId is used:

  • To identify the root package of our Java project. All our packages begin with the artifactId.
  • As name for our Eclipse project. Eclipse projects for gvSIG development have the same name as the artifactId.
  • When naming the jars: the names of jars that are generated for our project begin with the artifactId followed by the version of the project and the Maven classifier.

• There should be a strict separation between API and implementation.

  This seems obvious, but very often there is no such separation, and when there is a separation it is usually not as strict as is required by gvSIG.

  The main reason for this are issues such as:

  • How do we assess the scope of a change in the code? What would be the impact on the gvSIG application if we modify this?

    Having the APIs strictly defined greatly facilitates the response to this question.

  • How can we properly document the use of libraries? When the API and the implementation are separated, it is easier to focus on the API documentation than when it is mixed with the implementation.

  • How can we run automated tests on our library? If we have a clear and well-defined API, we can focus on preparing automated tests to check the specifications of the API so that we can easily verify whether a change in implementation will affect the usage of the API.

• There must be an automated test system to verify the functioning of the API in our project. Until now JUnit is being used to perform these tasks.

• The APIs must be documented and this documentation must be uploaded to a public website.

  For documentation of interfaces and classes of the APIs, Javadocs will be used. The API documentation should be complete and in English. To generate and deploy the documentation, the Maven tool for generating sites will be used.

• The dependencies of our project on other libraries must be indicated.

  This is done by keeping the ManageDependencies in the root of the Maven project updated.

• The project must come with a test plan. This test plan should work by way of a series of acceptance tests that the project should go through after every gvSIG build until the final version.

• User documentation of the project must be prepared in ReST (reStructured Text) format, preferably in English.

• The jars of the project must be deployed in a Maven repository, and a versioning policy must be followed corresponding with the changes made to the project. gvSIG has its own Maven repository in which to deploy its libraries, but you can use another if appropriate.

• A developers guide, preferably in English, to introduce developers in the use of the libraries of the project would be appreciated.

• When generating installable packages of your plugin for gvSIG, make sure that it has a unique build number. There must be a way to uniquely identify a distribution or packaging of your plugin that does not leave any doubt to which version it applies. Therefore, a unique build number must be assigned to each packaging for gvSIG.

To work with our project need a gvSIG 2.0 installed. You must also install the Development project wizard addon, available through the addons manager (Tools > Addons manager).

What is going to offer this extension?

Mainly this extension will give us the option Create plugin. Using this utility, will allow the creation of maven projects, following the project structure described above, according to the custom options you choose to work with this installation of gvSIG.

This utility can be found in the menu Tools the option Development:

After accessing Create plugin option, the extension will show a wizard. This wizard will guide you to create a template from our maven project associated with this instance of gvSIG. As the most interesting points, note that the wizard will require that you enter the name of our project, group_id (default org.gvsig) and the location to generate the plugin.

You will have also to select the template to use, being able to select between a basic project with spatial support or a project to show fortune cookies. The first one is the recommended one.

If you select the second template, in addition we need indicate the type of plugin to be developed (for details see section FortuneCookie a _ plugin gvSIG). Finally, we will tell to wizard if we want to generate the extension for gvSIG or not.

As a last step in the generation of our plugin, the tool will perform a prepare_workspace to leave our project ready. Perform maven tasks 'configure-eclipse-workspace','maven install' and 'maven eclipse:eclipse'.

Once created the project, closing gvSIG, start Eclipse and import the folder we created the project. To work with it, we import the parent project (org.gvsig.<project_name>) as all sub-modules (org.gvsig.<project_name>.lib.api, org.gvsig.<project_name>.lib.impl, org.gvsig.<project_name>.main and others according to the variant chosen).

Once the project has been imported into Eclipse, we'll just create our plugin and boot normally, using the project build.xml file, and using the mvn-install target.

Finally, once developed our plugin, use the Pack plugin option of gvSIG installation. A utility to generate binaries from our plugin and will allow us to distribute it as a separate plugin or included in an existing gvSIG installable.

The FortuneCookie project is a very simple example plugin that aims to serve as a template to be followed by the developer when implementing their own plugins.

But, what advantages gives us the use of the diferents FortuneCookies projects? In principle, the most direct benefit is pretty obvious, since the fact of working on fully implemented a complete project that compiles and runs, can focus more on developing the code than in configuration tasks. And is that all FortuneCookies projects have declared their POM files with all the minimum dependences to run, and to establish relationships between them.

Therefore, to say that we have a project that will provide a number of basic, complete, compilable and run structures from which begin our development.

It presents several implementations that allow the developer show the highlights to be covered by your plugin depending on which option best suits the nature of the project. The variants presented are:

• Basic. Develop the essential elements in any project, such as the API and implementation.
• With service providers. Presents the necessary structure to implement a plugin that makes use of service providers to perform their functions. It gives the basic variant of the SPI definition and implementation of two providers: one through FortuneCookies provided by a Web service, and another from a local text file.
• With graphical user interface (GUI). Add the basic variant the entire structure to develop the GUI project. Provides the API and implementation Swing module responsible for the GUI, among which is the definition of the panels and the various tools for management and visualization.
• With service providers and GUI. This project join the above two points into one.

Should you require more information on any of the alternatives mentioned are advised to consult the document org.gvsig.tools.service

Moreover there is the option of GUI providers. This will be the option if, in addition to the above, support is required for the acquisition of user interfaces provided by vendors (currently under construction).

• Compilar
• Tests unitarios
• Instalar
• Javadoc
• Site
• Obtener árbol de dependencias
• Otros

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.

En este apartado se definen los pasos necesarios para poder preparar un espacio de trabajo con el núcleo de gvSIG 2.0, así como compilarlo y generar instalables del mismo.

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:

  • In the Java preferences of Eclipse, indicate the JVM to be used to run projects.
  • Verify that Eclipse has the correct JVM set in the initial configuration, as starting Eclipse with the wrong JVM version can cause problems when running gvSIG.

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

  • GDAL: libgdal1-1.4.0, libgdal1-1.5.0 or libgdal1-1.6.0 package, depending on which is available in your distribution.
  • GRASS (through GDAL): libgdal1-1.4.0-grass, libgdal1-1.5.0-grass or libgdal1-1.6.0-grass, depending on the GDAL version that you installed. When you install this package, it will also install GRASS.
  • PROJ: proj package

  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.

The steps for creating an Eclipse workspace for working with gvSIG are as follows:

1. Start Eclipse and create a new workspace for gvSIG 2.0.

2. Set the encoding used in gvSIG (ISO-8859-1):

   Window > Preferences: General > Workspace > Text file encoding = ISO-8859-1
   

3. 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). 
   

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

   • Anonymous access with read only permission.
   • Access with read and write permission. For this you need a user in the infrastructure of gvSIG.

   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:

   • Subclipse.
   • Subversive.

   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:

   • trunk: latest development version.
   • tags: closed versions and builds, for which a tag is generated.
   • branches: development branches.

   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.

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

6. Open the Ant view by selecting the following menu option:

   Window > Show view > ant
   

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

   • library: build/libraries-pom/pom.xml
   • native library: build/libraries-jni-pom/pom.xml
   • extension: build/extension-pom/pom.xml

   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
     

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

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

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

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

    • The URL of the subversion server, which depends on whether public access with read only rights, or access with read and write rights (which requires a user name and password) is preferred.
    • The SVNKit version to use. It is necessary to check that this is the same as that of the subversion support plugin installed in Eclipse. As in the previous cases, accessing the Internet through a proxy requires the access for the SVNKIT library to be configured. In fact, this library reads the same configuration as the native client of subversion, whose configuration is described in Download the build project. More information is available in the users guide of SVNKIT
    • User name and password to access subversion, if applicable.
    • Whether to automatically create the Eclipse project configuration once the download is complete. If this option is deactivated, the Eclipse projects have to be generated either from the mvn eclipse option on the External tools menu or from the console with the instruction: mvn -P eclipse-project.

    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.

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

13. 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).

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

    • org.gvsig.annotation.lib.api
    • org.gvsig.annotation.lib.impl
    • org.gvsig.annotation.main
    • org.gvsig.annotation.swing.api
    • org.gvsig.annotation.swing.impl

    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:

      • Project name: The name of the parent root project to import. Ex: org.gvsig.annotation.
      • Use default location: Select this option.

      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:

    • org.gvsig.annotation
    • org.gvsig.annotation.app
    • org.gvsig.app.document.layout.app
    • org.gvsig.app.document.table.app
    • org.gvsig.exportto
    • org.gvsig.exportto.app
    • org.gvsig.geometrymeasurement.app
    • org.gvsig.hyperlink.app
    • org.gvsig.installer
    • org.gvsig.installer.app
    • org.gvsig.newlayer
    • org.gvsig.newlayer.app
    • org.gvsig.personaldb
    • org.gvsig.selectiontools.app
    • org.gvsig.symbology
    • org.gvsig.symbology.app

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.

mvn configure eclipse workspace

mvn eclipse:add-maven-repo -Declipse.workspace=WORKSPACE_PATH

mvn eclipse

mvn -P eclipse-project

mvn eclipse clean

mvn eclipse:clean

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:

• libGPE
• libGPE-XML
• libGPE-GML
• libGPE-KML
• extGPE-gvSIG

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:

• gvsig-base: conjunto de proyectos básicos para tener un build de gvSIG mínimo con soporte vectorial sobre algunos formatos de archivo básicos. Se puede emplear durante el desarrollo de nuevas extensiones que no dependan de otros proyectos, sin cargar otras extensiones.
• gvsig-standard: conjunto de proyectos de un build estándar de gvSIG. Incluirá habitualmente el conjunto de proyectos que conformarán un build oficial 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:

  • mvn-clean
  • mvn-install
  • mvn-install-without-tests: equivalente a mvn -Dmaven.test.skip=true install
  • mvn-reinstall: equivalente a mvn clean install
  • mvn-reinstall-without-tests: equivalente a mvn -Dmaven.test.skip=true clean install

  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:

  • gvSIG Linux
  • gvSIG Mac
  • gvSIG Windows

  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.

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

Para compilar un proyecto desde maven, basta con invocar el objetivo:

mvn compile

Desde eclipse, se ha creado un lanzador en la opción de External Tools que permite compilar desde maven fácilmente, con el nombre: mvn compile.

Antes de usar este lanzador, deberemos seleccionar o estar editando algun archivo del proyecto que vamos a compilar, ya que se emplea la variable project_loc para invocar a maven sobre un proyecto.

Hay que tener en cuenta que el proyecto de eclipse está configurado de forma que las clases compiladas se generan en el mismo directorio que lo hace maven, así que, por lo general, al invocar este objetivo sobre un proyecto que tengamos abierto en eclipse, ya esté todo compilado y no haga nada.

Además de compilar, si queremos lanzar los tests unitarios de nuestro proyecto desde maven, emplearemos el objetivo:

mvn test

Finalmente, si queremos que el código que compilemos en un proyecto, esté disponible para otros proyectos que dependendan del mismo, deberemos generar el o los archivos .jar correspondientes, e instalarlos en el repositorio local de maven. Para ello emplearemos el objetivo:

mvn install

El objetivo install, además de compilar, lanza los tests unitarios del proyecto. Si queremos hacer la instalación sin lanzarlos, podemos usar el objetivo:

mvn install (no tests)

El equivalente desde consola es:

mvn -Dmaven.test.skip=true install

Los proyectos de gvSIG están configurados para generar, además del archivo .jar con las clases compiladas, otro archivo .jar con los fuentes. Esto nos será útil al enlazar las dependencias en maven y su uso desde los proyectos de eclipse.

Por otro lado, si queremos hacer una instalación y compilación desde cero, podemos usar el objetivo:

mvn clean install

Si nuestro proyecto es una extensión de gvSIG, existe una tarea adicional, además de la compilación y generación de archivos .jar: la instalación de la extensión sobre gvSIG.

Para ello se ha creado el siguiente perfil en maven:

install-extension: copia los archivos .jar generados, junto con el resto de recursos de la extensión (configuración, properties con textos multiidioma, imágenes, etc.) a gvSIG.

Dicho perfil está activado por defecto en los proyectos de tipo extensión, cuando invocamos al objetivo:

mvn install

Una vez que hayamos terminado un determinado desarrollo en nuestro proyecto, y queramos que esté disponible para otros proyectos, sin que éstos tengan que descargar el código fuente de nuestro proyecto y compilarlo, podemos publicarlo en el repositorio de maven de gvSIG.

Este paso adicional se realiza a través del objetivo:

mvn deploy

Este objetivo realiza un mvn install y, a continuación, sube los artefactos generados, como el archivo .jar con las clases compiladas, al repositorio de maven.

Los proyectos de gvSIG están configurados de forma que el repositorio al que se suben los artefactos es el de gvSIG.

Como se comenta en el apartado de compilación, en gvSIG se genera, por defecto, tanto el archivo .jar con las clases compiladas como el archivo .jar con el código fuente, que también se subirá al repositorio.

Además, si estamos publicando una versión con cambios significativos, será conveniente publicar también el javadoc en un archivo .jar. Para ello activaremos el perfil release con el siguiente objetivo desde eclipse:

mvn deploy release

Desde consola, el uso de maven directo es el siguiente:

mvn -P release deploy

TODO

Maven permite la generación de documentación a partir de los fuentes de un proyecto, como por ejemplo el javadoc.

Para ello existen una serie de plugins especiales de maven para la generación de informes.

Por ejemplo, para generar el javadoc usaremos el plugin correspondiente de la siguiente forma:

mvn javadoc:javadoc

Además de la generación de informes individuales, maven permite la generación de lo que llaman el site. Este consiste en un conjunto de páginas de informes de maven enlazadas, con un menú que nos permite navegar por todos los documentos generados.

De hecho, este mini website generado con maven es lo que emplean muchos de los proyectos Java de apache como website del proyecto.

Para los proyectos de gvSIG, se ha preconfigurado una serie de plugins con las opciones adecuadas del proyecto. Además, existen una serie de páginas que muestran información extraída del archivo pom.xml del proyecto, por lo que será importante completar y mantener actualizada dicha información.

En los proyectos que se generen usando los arquetipos de maven, el archivo pom.xml ya lleva los atributos necesarios predefinidos, a falta de rellenar y completar con valores reales.

Para generar el site invocaremos el objetivo:

mvn site

Esto nos generará la documentación dentro de nuestro proyecto, en la carpeta:

target/site

TODO

• Links javadoc, la variable site-repository y referencias entre proyectos.
• Publicación del site en el servidor público de gvSIG.

Si vamos a añadir o actualizar una dependencia externa en un pom.xml en un proyecto de gvSIG, tendremos que hacer lo siguiente:

Primero, nos asegurarnos que la dependencia y la versión que nos interesa está ya disponible en algunos de los repositorios oficiales de maven. Para ello tenemos dos opciones:

• Usar el buscador del repositorio de maven.org

• Realizar una búsqueda manual, mediante google o inspección directa de alguno de los repositorios alternativos de maven.

Si hemos encontrado la dependencia deseada, ya podemos modificar el pom.xml, pues ya sabemos que está disponible para todos.

Si no hemos encontrado la dependencia, habría que pedir al proyecto original que suban la dependencia al repositorio oficial de maven, proporcionándoles la información necesaria para ello para que les sea más sencillo:

Así, contribuiremos con la comunidad a facilitar el uso de la librería correspondiente a través de maven. En algún proyecto es posible incluso que nos propongan que nos encarguemos de actualizar nosotros el repositorio de maven con nuevas versiones de una librería.

Si desde el proyecto original no se quiere hacer o se tarda mucho, podemos subirla temporalmente al repositorio maven de gvSIG, quitándola cuando esté disponible en el repositorio oficial.

mvn deploy:deploy-file -Durl=REPO_URL
                   -DrepositoryId=some.id
                   -Dfile=your-artifact-1.0.jar
                   [-DpomFile=your-pom.xml]
                   [-DgroupId=org.some.group]
                   [-DartifactId=your-artifact]
                   [-Dversion=1.0]
                   [-Dpackaging=jar]
                   [-Dclassifier=test]
                   [-DgeneratePom=true]
                   [-DgeneratePom.description="My Project Description"]
                   [-DrepositoryLayout=legacy]
                   [-DuniqueVersion=false]

mvn deploy:deploy-file -DgroupId=$LIBRARY_GROUPID
                   -DartifactId=$LIBRARY_ID
                   -Dversion=$LIBRARY_VERSION
                   [-Dclassifier=$LIBRARY_CLASSIFIER]
                   -Dpackaging=jar
                   -Dfile=$LIBRARY_JAR
                   -Durl=$REPOSITORY_URL                  
                   -DrepositoryId=gvsig-repository

mvn deploy:deploy-file -DgroupId=org.nfunk \
               -DartifactId=jep \
               -Dversion=2.4.0 \
               -Dpackaging=jar \
               -Dfile=jep.jar \
               -Durl=dav:https://devel.gvsig.org/m2repo/j2se \
               -DrepositoryId=gvsig-repository

A quick howto prepared in the process of creating the gvSIG 2.0 installer using installjammer:

• Download last final version of installjammer (http://www.installjammer.com/. While creating this document the last final version available was the 1.2.15 one, but it had a bug with link files, so we have used an hourly build of the 1.2 branch.

• Run installjammer and click on the new installer icon.

• Go through the wizard options filling the required information. Of special interest for gvSIG:

  • Theme selection: Modern Wizard
  • Platforms: Linux X86, Linux X86 64 and Windows. (tar and zip ones kill installjammer when building)
  • Additional features: all checked but the "Allow users to select custom components in your install", as that will be managed through the gvSIG own installer.

• Add files to install.

  • Create a file group for the common files non platform dependent, called gvSIG base. Add to it the product directory, checking everything but the platform dependent files and the plugins that won't be installed in the minimal installation.

    Add to it also the $HOME/.depman/data folder to be copied to the root installation folder.

  • Create a file group for each supported platform (linux, windows, etc.). Add to them the product and $HOME/.depman/lib and bin folders and select only the files or folders of each platform

  When you add a folder or file to a group, InstallJammer stores the absolute path. That would make a bit difficult to share the installer configuration. To solve it, Virtual Text variables can be used:

  • Add a %BaseDir% Virtual Text variable pointing to your gvSIG installation. Then, for each product folder added in the file groups, edit the Location property and set it to <%BaseDir%>.
  • Add three more variables to point to the data, lib and bin folders too, called:
    • BaseNativeLibsDir: path to the $HOME/.depman folder.
    • Lini386NativeLibsDir: path to the $HOME/.depman/lib folder.
    • Wini386NativeLibsDir: path to the $HOME/.depman/bin folder.

• Add license panel:

  1. Open Install Panes and Actions > Standard Install

  2. After the Welcome screen add a License agreement pane.

  3. By default the license must be written in the configuration pane options. To read the license from a file, add a Execute script after the pane, with Execute action = Before pane is displayed and the tcl script:

     set file [::InstallAPI::FindObjects -alias "ProgramLicense"]
     set file [$file srcfile]
     ::InstallAPI::SetVirtualText -virtualtext LicenseText -value [read_file $file]
     

  4. The file with the license contents must be updated with the alias ProgramLicense. Go to Groups and files, look for the license file LICENSE.txt and into the properties update the Alias field.

• Find java executable while installing:

  1. Create an action group called Find Java Actions, with the same name in its alias property (very important or it won't be shown when called from a pane action).
  2. Add a Locate Java Runtime action to the group and set the Minimum Version property to 1.5.
  3. Add a Message Box action to the group to be shown when the java executable is not found. Set the properties:
     • Icon: error
     • VirtualTextField: JavaNotFound
     • Message: <%JavaNotFound%>
     • Add a condition of type String is Condition with the properties: - Operator: false - String: <%JavaFound%>
  4. Add a Exit action to the group to exit the installer after the previous message box is shown if the java executable is not found. Set properties:
     • Exit code: -1
     • Add a condition of type String is Condition with the properties: - Operator: false - String: <%JavaFound%>
  5. Add a Execute Action to the Welcome Screen pane with the properties:
     • Alias: Find Java
     • Action: Find Java Actions

• Replace variables in the gvSIG linux launcher (gvSIG.sh):

  1. Add a Replace Text In File action into the Copying files pane, just after the Install Everything one.

  2. Configure the added action with the properties:

     • Files: gvSIG.sh

     • String Map:

       "JAVA_HOME=${JAVA_HOME}" "JAVA_HOME='<%JavaHome%>'"
       "GVSIG_HOME=`pwd`"  "GVSIG_HOME='<%InstallDir%>'"
       

• Launch the gvSIG add-ons installer before the installation process end:

  1. Add a Custom Text Pane 1. To internationalize the text properties, save the project and look for the stored values in the .mpi file. It will be something like:

     54A9E67A-F932-CDD4-6F9A-8842AAE31ACC,Title
     

     Add the properties to be translated to the msg files located in build/projects/gvsig-standard/gvsig-standard-installer/src/main/installjammer

  2. Add a new Action group called Install addons actions, with the same value for the Alias property.

  3. Add to the group an action to launch the Addons manager in linux (or other non windows OS), using a Execute External Program action with the properties:

     • Alias: Launch addons manager not windows
     • Console title: <%AppName%> add-ons manager
     • Program command line: <%ProgramExecutable%> --install --installURL=http://gvsig-desktop.forge.osor.eu/gvSIG-desktop/dists/<%Version%>/packages.gvspki language=<%Language%>
     • Working Directory: <%InstallDir%>
     • Add a condition of type Platform Condition so it is launched only in non windows OSs, with the properties: - Operator: is not - Platform: Windows

  4. Add to the group an action to launch the Addons manager in windows, using a Execute External Program action with the properties:

     • Alias: Launch addons manager windows
     • Console title: <%AppName%> add-ons manager
     • Program command line: <%InstallDir%>/gvsig-package-installer.exe --install --installURL=http://gvsig-desktop.forge.osor.eu/gvSIG-desktop/dists/<%Version%>/packages.gvspki language=<%Language%>
     • Working Directory: <%InstallDir%>
     • Add a condition of type Platform Condition so it is launched only in windows, with the properties: - Operator: is - Platform: Windows

  5. Add a Execute Action to the Welcome Screen pane with the properties:

     • Alias: Install addons
     • Execute action: before next pane is displayed
     • Action: Install addons actions

• Add support to show the README contents in Spanish of English. By default installjammer configures the project to show the contents of only one file. To add this support is easy:

  1. Add a README panel with the Spanish contents by creating a copy (Copy and then Paste) of the View Readme Window action into the Finish actions group. Rename it to View Leeme Window and set the properties:
     • Text File: <%InstallDir%>/LEEME.txt
     • Add a condition so it only runs in Spanish, of type String Match Condition with the properties:
       • Match Case: No
       • Operator: matches
       • Pattern: es*
       • String: <%Language%>
     • Change the File Exists Condition property:
       • Filename: <%InstallDir%>/LEEME.txt
  2. Add a condition to the View Readme Window action so it only runs in non Spanish languages, of type String Match Condition with the properties:
     • Match Case: No
     • Operator: does not match
     • Pattern: es*
     • String: <%Language%>

To publish an official version of gvSIG Desktop in www.gvsig.org, the following steps must be followed:

1. Rename the binaries with the following nomenclature:

• gvSIG-[major-number]_[minor-number]_[revision-number]-[Build-Number]-[final_pilot_alpha_RCx_prot]-[operat_syst-3_letters]-[Processor_Type]-[JVM_description]-[JVM].[file_extension].
  For example: gvSIG-1_9-1245-final-lin-i586-withjre-j1_6.bin, gvSIG-1_9-1264-RC2-win-i586-j1_5.bin

2. Rename source code files (if it's a file) with the following nomenclature:

• gvSIG-[major-number]_[minor-number]_[revision-number]-[Build-Number]-[final_pilot_alpha_RCx_prot]-[operat_syst]-src.[file_extension].
  For example: gvSIG-1_9-1265-final-lin-src.zip

3. Upload binaries and source code to OSOR.eu:

• In the Forge of the project, being logged, go to Files (for example in gvSIG Desktop: http://forge.osor.eu/frs/?group_id=89)
• In every project, 2 Packages will be created: one for stable versions and another one for unstable ones, for example: gvsig-desktop (final ver.), gvsig-desktop (other ver.), gvsig-network-ext. (final v.), gvsig-mobile (final v.)...
• In the corresponding Package, the Release must be created. For example:
  For example: gvSIG 1.9 RC2
• Every file will be uploaded to this release.

4. Upload the manuals to OSOR.eu:

• They will be renamed like this: 
  • gvSIG-[major-number]_[minor-number]_[revision-number]-man-[manual_version]-[language_2_letters].[file_extension]
                For example: gvSIG-1_1-man-v1-en.pdf
• In the Forge of the project, being logged, go to Files (for example in gvSIG Desktop: http://forge.osor.eu/frs/?group_id=89): 
  • A "Releases" folder must be created (if it doesn't exist)
  • Inside that folder, a new folder called as the name of the version, with 2 figures (eg: 0.3) must be created
  • Inside that folder, a new folder called as the name of the version, with 3 figures (eg: 0.3.0) must be created
  • Manuals in pdf format will be uploaded to this last folder.

To publish an official version of gvSIG Mobile in www.gvsig.org, the following steps must be followed:

1. Rename the binaries with the following nomenclature:

• gvSIG_Mobile-[gvSIG_Mobile_version]-[Status]-[operat_syst]-[Processor_Type]-[JVM_description].[file_extension].
  For example: gvSIG_Mobile-1_0-final-WMX-forPhoneME.cab,  gvSIG_Mobile-0_3-Pilot-WMX-forPhoneME.cab, gvSIG_Mobile-0_3-RC2-WMX-forPhoneME.cab
  

2. Rename source code files (if it's a file) with the following nomenclature:
   
   
   • gvSIG_Mobile-[gvSIG_Mobile_version]-[Status]-src.[file_extension].
     For example: gvSIG_Mobile-1_0-final-src.zip,  gvSIG_Mobile-0_3-Pilot-src.zip
3. Upload binaries and source code to OSOR.eu: 
   • In the Forge of the project, being logged, go to Files (for example in gvSIG Mobile: http://forge.osor.eu/frs/?group_id=214)
   • In every project, 2 Packages will be created: one for final versions and another one for versions on development, for example: gvsig-mobile (final ver.), gvsig-mobile (other ver.).
   • In the corresponding Package, the Release must be created. For example:
     • gvSIG Mobile 0.3 Pilot
   • Every file will be uploaded to this release.
4. Upload the manuals to OSOR.eu:

• They will be renamed like this: 
  • gvSIG_Mobile-[gvSIG_Mobile_version]-[Status]-man-[manual_version]-[language_2_letters].[file_extension] 
                For example: gvSIG_Mobile-0_3-Pilot-man-v1-en.pdf
• In the Forge of the project, being logged, go to Files (for example in gvSIG Mobile: https://forge.osor.eu/docman/?group_id=214):
  • A "Releases" folder must be created (if it doesn't exist)
  • Inside that folder, a new folder called as the name of the version, with 2 figures (eg: 0.3) must be created
  • Inside that folder, a new folder called as the name of the version, with 3 figures (eg: 0.3.0) must be created
  • Manuals in pdf format will be uploaded to this last folder.
    
     

In gvSIG the SLF4J library is used as a logging API.

The Simple Logging Facade SLF4J is a framework that is designed to abstract the underlying logging system. As Log4j is the most popular logging system in use, the framework's API is very similar to simply removing the direct dependence of this system. This framework is therefore an abstraction layer of the logging system and will allow us to change the underlying components without having to undertake major recoding of the application.

// Those lines produce the same results. The second one has parameters that reduce the overhead when debugging is disabled
LOG.debug("The new entry is "+entry+"."); 
LOG.debug("The new entry is {}.", entry);

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class MyClass
{
    private static final Logger LOG = LoggerFactory.getLogger(MyClass.class);
    ...

LOG.warn(String message);
LOG.warn(String message,Object arg1);
LOG.warn(String message,Object[] arg1);
LOG.warn(String message, Throwable arg1);
LOG.info(String message);
LOG.info(String message,Object arg1);
LOG.info(String message,Object[] arg1);
LOG.info(String message, Throwable arg1);
LOG.error(String message);
LOG.error(String message,Object arg1);
LOG.error(String message,Object[] arg1);
LOG.error(String message, Throwable arg1);
LOG.debug(String message);
LOG.debug(String message,Object arg1);
LOG.debug(String message,Object[] arg1);
LOG.debug(String message, Throwable arg1);
LOG.trace(String message);
LOG.trace(String message,Object arg1);
LOG.trace(String message,Object[] arg1);
LOG.trace(String message, Throwable arg1);

LOG.isErrorEnabled();
LOG.isWarnEnabled();
LOG.isInfoEnabled();
LOG.isDebugEnabled();
LOG.isTraceEnabled();

private Integer temperature;

public void setTemperature(Integer temperature) {

    LOG.debug("Setting temperature to {}. Old temperature was {}.", temperature, this.temperature);

    this.temperature = temperature;

    if(temperature.intValue() > 50) {
      LOG.info("Temperature has risen above 50 degrees.");
    }
}

private Integer temperature;

public void setTemperature(Integer temperature) {

    LOG.debug("Setting temperature to {}. Old temperature was {}.", temperature, this.temperature);

    this.temperature = temperature;
    addToTemperatureLog(temperature);

    if (LOG.isDebugEnabled()) {
        LOG.debug("The current average temperature is {} Celsius", calculateAverageTemperature());
    }
}

The following sections describe some of the main issues to consider when migrating a project (library or extension) from gvSIG 1.9 to gvSIG 2.0. These instructions will be largely applicable to projects being migrated from earlier versions as well.

A new project nomenclature should be defined, which should coincide with the main java package of the project, with the base names for jars that are generated or, also, with the artifactID of the maven project.

An example of this nomenclature would be:

extQuickInfo -> org.gvsig.quickinfo

gvSIG 2.0 has been migrated from ant to maven as a tool for constructing projects. Therefore, the ant build.xml file should be replaced with a maven pom.xml file.

Documentation on the pom.xml file format, as well as general maven documentation, can be found on the maven project website.

There is also a brief introduction and description of how to use maven in the gvSIG 2.0 development guide.

In addition, maven has a default project structure that allows the most common construction operations to be performed with a minimum of configuration. Adapting the project structure for migrating to the default maven structure is therefore quite convenient.

On the other hand, it is more convenient to create a new project from the maven templates or archetypes, and then to migrate the content from the old to the newly created project, rather than trying to convert the old project directory to the maven format.

These maven project templates (archetypes) allow us to create a simple project with everything needed to start working. There are many archetypes available:

• If it is an internal project, use the create library or create extension archetype, according to the type of project required.

  If the project to be migrated is an extension, then the correspondence between locations in the old and the maven directory is as follows:

  • Sources: src -> src/main/java
  • Source tests: src-test -> src/test/java
  • Multilingual texts: config -> src/main/resources/locale
  • config.xml: config -> src/main/resources/config
  • Images: images -> src/main/resources/images
  • about.htm: config -> src/main/resources/about
  • build.number: [RAÍZ] -> src/main/resources

• If this is an external project, follow the instructions in the document Creating our project to create the initial project structure.

Virtually all the code base of gvSIG projects has been migrated to the package nomenclature of org.gvsig.xxx.

When migrating a project, imports should be updated in the same class. Eclipse provides tools to easily make the necessary changes.

A quick way of doing this, for example, is in the package manager to select all classes in the project, right-click on them and then select Source > Organize Imports.

On the other hand, if the project being migrated belongs to the gvSIG project itself, the packages should be renamed to also begin with org.gvsig.

The logging API to use in gvSIG 2.0 is the SLF4J library. If the project being migrated is using another logging API, such as Log4J or java.util.logging, then it needs to be replaced with the SLF4J logging API. You can find more information on SLF4J in the section on logging in the development guide

In general, the steps needed to migrate from Log4J to SLF4J are:

1.- Replace the Log4J import classes with those of SLF4J:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
// substituting the import of Log4j ...
// import org.apache.log4j.Logger;

2.- Change the Logger definition:

private static final Logger LOG = Logger.getLogger(MyClasser.class);
...

To:

private static final Logger LOG = LoggerFactory.getLogger(MyClass.class);
...

3.- Use message parameters where appropriate. For example:

LOG.debug("Point values: X = " + point.getX() + ", Y = " + point.getY());
...

To:

LOG.debug("Point values: X = {}, Y = {}", point.getX(), point.getY());
...

gvSIG 2.0 supports Java version 1.5 or higher, except in joint projects with gvSIG mobile.

When migrating a project, we need to decide if we want the code to work on gvSIG mobile or not. If so, it is usually not all the code that needs to be compatible, only the library or the library API. It is therefore advisable to have these in a project separate from the rest and then to validate, unless the project compiles to Java ME CDC.

If the project does not need to be compatible with gvSIG mobile, or a part thereof, it is compiled with Java 1.5 or higher.

Due to the compilation with Java 1.5, it is advisable to remove the warnings that could appear in the code in Eclipse, such as the use of the classes of collections without the use of generics.

Dependencies in gvSIG 2.0 projects are managed from maven.

In addition to this change, there are a number of developments that affect how dependencies are defined in gvSIG:

• All dependencies are defined with their version.
• External dependencies are registered with their version in the pom.xml root configuration for all projects (see project org.gvsig.maven.base.pom). Therefore, a project only has to define its dependencies without indicating the version, as these have already been defined in the configuration project.
• All dependencies should be available in the official repositories of maven or osgeo. If not, they can be uploaded from the gvSIG repository.
• Dependencies with other gvSIG projects are defined in the same way as for any external project, indicating the groupId, artifactId and version.
• Some of the projects in gvSIG 2.0 have been divided in turn into other projects (for example, the libFMap project), so we must determine what our actual dependencies in gvSIG 2.0 are.
• Many projects begin to generate separate jars of their API, SPI, implementation, providers, etc. In general we rely solely on the API or SPI jars to build, and rely on the others only for performing tests.

You can find more information about the management of dependencies in the section How to add or update a dependency in the gvSIG 2.0. development guide.

In gvSIG object persistence is used, amongst other things, to save the project, symbols, etc.

In gvSIG 2.0 a new API and persistence implementation has been developed. It is compatible with Java ME CDC for use in the gvSIG Mobile project and completely replaces the previous API.

Therefore, we have to migrate all uses of persistence in our project so that they use the new API, which is available in the org.gvsig.tools.persistence package of the org.gvsig.tools project.

For more information about using the new persistence API, you can consult the persistence development guide.

Based on experience gained from migrating projects to date, we recommend that when migrating a project you don't rely on persistence as implemented with the old API, as it is often closely linked to the conditions leading to the earlier persistence, assumed a lot more work, besides making assumptions about the flow of persistence.

Instead we recommend that the migration of persistence be addressed as if it were being implemented for the first time, looking only at the class to be persisted, and which of its attributes to persist.

With the new API it is much easier to persist objects, since most of the time the attributes of the classes can be persisted directly, without having to manage their conversion between object and String.

In versions prior to gvSIG 2.0, a common practice when implementing object cloning was to use persistence. An object was persisted and then 'unpersisted' to obtain a copy.

However, in gvSIG 2.0 this method will probably not work, as the new persistence API takes control of object references to avoid duplicating objects already loaded on the system, and so you may not get the desired results.

To implement object cloning a new API has been defined in org.gvsig.tools, as well as a development guide that shows how to implement and use cloning.

There is often the need for some kind of initialisation when loading library projects. Up until now, every project has carried out this initialization on their own using different mechanisms.

To standardise and unify the operation of all projects, a library initialization mechanism has been defined in gvSIG 2.0, for which there is a short development guide showing how to use it in our projects.

Extension points have undergone two major changes in gvSIG 2.0:

• Changes to the API.
• Project change, will now be in the org.gvsig.tools project.

You can find more information in the developer documentation on extension points.

The old libFMap project was divided into a number of subprojects which provided the core functionality. These projects, in turn, generated various artefacts or .jar files, which also affect the dependencies that we will include in our projects.

The main projects that have emerged from the former FMap are:

• org.gvsig.fmap.geometry (libFMap_geometries)
• org.gvsig.fmap.dal (libFMap_dal)
• org.gvsig.fmap.dal.file (libFMap_dalfile)
• org.gvsig.fmap.dal.db (libFMap_daldb)
• org.gvsig.fmap.dal.index.spatial (libFMap_dalindex)
• org.gvsig.fmap.mapcontext (libFmap_mapcontext)
• org.gvsig.symbology
• org.gvsig.fmap.control (libFMap_controls)

The following section discusses some of the major changes in functionality.

In gvSIG 2.0 a separate project for geometry libraries has been constructed. It has evolved from what was in previous libraries and provides a separation between the API, implementation and operations on geometries.

There is development documentation available on the library, where we can see major changes at the API level, and a description of the model geometry that defines the library.

One of the major changes is that classes such as FShape have disappeared, and will be substituted by the interfaces available in the geometry library, such as Geometry and GeometryManager.

For example, where constant shape types were used to define the FShape class, there are now two options:

• Using geometry operations, we can associate types and/or subtypes of geometries.
• Using constant types and subtypes that are defined in the Geometry.TYPES and Geometry.SUBTYPES interfaces. This option has a big problem, in that these types and subtypes do not cover all possibilities, but only those defined initially as defaults. From now on libraries or extensions can be registered on their own, so if you use this option, instead of registering operations, our functionality won't function properly with these other geometry types.

In any case, if we choose the latter option, then we have a table showing the equivalents between the types of shapes and types of geometries of the new library:

(*) In the gvSIG 2.0 geometry library, any geometry may be 2D, 3D, 2DM, etc. This feature is managed through the subtype of a geometry (see Geometry.SUBTYPES for predefined subtypes), so there is no equivalent for this constant in Geometry.TYPES.

One of the main changes in the development of gvSIG 2.0 has been the replacement of all previous data access methods with a new API and implementation, namely the DAL (Data Access Library).

This API combines access to both tabular and geometric data, in addition to defining a common core API between vector and raster data.

For more information about using the API, as well as the development of data providers, consult the DAL development guide.

All code related to Mapcontext, symbology and labelling has been moved to a separate project: org.gvsig.fmap.mapcontext (libFMap_mapcontext). Those parts relating directly to mapcontext, the viewport, layers, etc. have not changed much since the previous version, except for changes required to conform to the rest of gvSIG 2.0.

The main change has been to extract the symbology and labelling API, as this API and the rest of mapcontext are a joint project between gvSIG desktop and gvSIG mobile.

The implementation of symbology and labelling now has its own project: org.gvsig.symbology. This is the implementation that is used in gvSIG desktop; gvSIG mobile has developed its own implementation.

Therefore, when a project is migrated to gvSIG 2.0 it will be affected mainly by:

• The extraction of the symbology and labelling API. These APIs have hardly been modified. The main change is that there are now managers for obtaining, creating and registering symbols, legends and labelling strategies. The entry point for accessing these managers will be the MapContextLocator.
• The introduction of new symbols, legends and labelling strategies. We use the previous managers to register them.
• A few changes to the rest of mapcontext, especially those related to data access, and issues such as InfoByPoint.
• Renamed all the starting packages with:
  • org.gvsig.fmap.mapcontext: main package of the org.gvsig.fmap.mapcontext project (libFMap_mapcontext).
  • org.gvsig.symbology: main package of the symboloy and labelling implementation project org.gvsig.symbology.

At the moment the development guide doesn't have any documentation available on this development.

A new project has been created where all the code related to MapControl is located: org.gvsig.fmap.control (libFMap_controls). This project also contains other graphical controls that depend on the other FMAP APIs, such as DAL.

For example, swing components, used from the gvSIG document table, have been created to display Feature tables. But now it is very easy to create applications outside of gvSIG, or to include other use cases that aren't from the document table, that show Feature data in tabular form.

Apart from the general changes to packages, and the adaptation to the other changes, this project has a few changes affecting the API. Some examples are:

• Rename the addCombinedTool method to addCombinedBehavior
• ...

TODO

Changes to the project API and documents:

• View -> IView

TODO

• Use the org.gvsig.i18n API directly. That is, instead of:

  String text = PluginServices.getText(this, "Coordinates");
  

  Use:

  String text = Messages.getText("Coordinates");
  

• Maintain a separation between the API, SPI, implementation and providers.

Version 1.9 had an addMapTool method in the MapControl class but Version 2.0 doesn't.

Where can it be found?

The addMapTool method has simply been renamed addBehavior.

In version 1.9 the FieldDescription class was used to query the attributes of a field in a table.

How is this done now?

In version 2.0 all data access has changed. To query the attributes that describe a field in a table you have to make use of the FeatureAttributeDescriptor class.

A vector layer has a FeatureStore, which in turn has a defaultFeatureType, that defines the structure of the feature by means of the FeatureAttributeDescriptor.

The getSource and getRecordset methods were used to access a layer's data.

What is used now?

In version 2.0 the vector layers have a getFeatureStore method that returns a FeatureStore and provides access to both spatial and alphanumeric data.

If you just want to get all the layer's features you can invoke the getFeatureSet method of FeatureStore.

Some parts of my Extension were cast to the View class in order to access the view window.

Where is this class now?

The View class has been renamed and should not be used for casting. If you do need it, it will probably be sufficient to cast the IView interface.

How can I find the extent of the view port?

There is no longer a getAdjustedExtent method.

There has been a systematic elimination of all the methods that worked with an Extent. These have been replaced by methods for managing an Envelope. Operations on the gvSIG extent treated it as a 2D rectangle, which, with the emergence of more complex geometries, is no longer correct.

The methods that used to work on an Extent now work with an Envelope, and so have been renamed.

The getAdjustedExtent method has now become getAdjustedEnvelope.

I have code that works with geometries that follow the JTS model.

How can I convert a gvSIG Geometry to JTS format?

You can do this by invoking:

Geometry geom;
com.vividsolutions.jts.geom.Geometry jtsGeom;

jtsGeom = (com.vividsolutions.jts.geom.Geometry) geom.invokeOperation(ToJTS.CODE, null);

I have a variable of type View and would like to access the getModel method. Where I can find it in 2.0?

The code in 1.x was something like:

IWindow window;
MapContext mapa = ((View) window).getModel().getMapContext()

The code in 2.0 is:

IWindow window;
MapContext mapa = ((IView) window).getViewDocument().getMapContext();

To get an extension point:

The code in 1.x was something like this:

ExtensionPoint pe;
String name;
pe = (ExtensionPoint) ExtensionPointsSingleton.getInstance().get(name);

In 2.0 the code is:

ExtensionPoint pe;
String name;
pe = ToolsLocator.getExtensionPointManager().get(name);

The createLayer method of the LayerFactory class is deprecated. How do I create a raster layer?

The code in 1.x was something like this:

String filename;
BaseView view;
FLayer newLayer = LayerFactory.createLayer(filename, "gvSIG Image Driver",new File(filename), view.getProjection());

In 2.0 the code is:

String filename;
IView view;
DataStoreParameters parameters = DALLocator.getDataManager().createStoreParameters(RasterStoreProvider.NAME);
parameters.setDynValue("filename", filename);
parameters.setDynValue("srs", view.getViewDocument().getMapContext().getProjection());
FLayer newLayer = MapContextLocator.getMapContextManager().createLayer(filename, parameters);

The gvSIG subversion repository was moved from its own server at the gvsig.org domain to a server hosted in OSOR during the week of April 12th 2010.

The easiest way is to do a checkout of the project again in a new workspace. However, if we have changes to upload, another option is to change the reference to the subversion server in our own workspace.

At first, we have two options for this:

• From eclipse: (for lack of testing) we can use the option Team > Disconnect on a project, and then Team > Share project indicating the new URL to use.

• From console: we can use the option of the subversion client svn switch --relocate OLD_URL NEW_URL folder. For example, to migrate the build project of the 2.0 (from the same build project), we'd use:

  svn switch --relocate \
    https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/build \
    https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/build \
    .
  

All of this, project by project. If we have a unix shell (we are on linux, mac, windows with the cygnus utilities, etc.) we can use the following instructions (including to create a script) to migrate a complete workspace of the gvSIG core:

# Andami
svn switch --relocate \
    https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/frameworks/_fwAndami \
    https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/frameworks/_fwAndami \
    _fwAndami

# Root projects
for project in build binaries org.gvsig.core.maven.dependencies; 
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/${project} \
    https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/${project} \
    ${project}; 
done

# Applications
for project in app*; 
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/applications/${project} \
    https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/applications/${project} \
    ${project}; 
done

# Libraries
for project in lib*; 
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/libraries/${project} \
    https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/libraries/${project} \
    ${project}; 
done

# Extensions
for project in ext* org.gvsig.symbology; 
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/extensions/${project} \
    https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/extensions/${project} \
    ${project}; 
done

The differences between versions 1.X and 2.X are very important in some areas of the application. There are important changes relating to:

• Construction of the project having moved from ant to maven.
• Standardisation of java package names.
• Data access architecture. The entire data access section has been rewritten in gvSIG.
• Re-engineering of the geometry access libraries.
• Rewriting of the mechanisms used for writing and retrieving data from the files of a gvSIG project.
• Rewriting of the mechanisms used for persisting the user data associated with a plugin.
• Change of the logging mechanism being used, from log4j to slf4j.
• The mechanism for packaging and installing plugins for gvSIG.
• The introduction of mechanisms for maintaining a separation between the API and implementation in the gvSIG code.
• Separation of the logic from the user interface. This is mainly in the parts of the application that have to be rewritten. In the parts where rewriting isn't necessary it can remain as it was.
• A guide to the coding conventions to be followed in gvSIG code has been developed.

In the light of these changes, there is no simple answer to the question What needs to be taken into account when initiating a development in the 1.X line and then later migrating to the 2 line?

The first issue that arises is that compatibility can't be maintained. Upon further reflection, there are some recommendations that can be followed, some more difficult than others. Some of them are listed here and developers will have to decide on their applicability to their projects:

• Never modify gvSIG source code. Although this may seem obvious, don't modify the gvSIG code, use it as is. There are extension points in gvSIG that allow you to click on many of the gvSIG features in order to customize them. For those features where this is not available tell us so that we can study them and provide a solution.

• Work with a gvSIG installable, not with the source. This is more than just a recommendation. Don't embed the gvSIG source along with your development in its workspace. Rather create a separate workspace for your development when deploying your plugins in a gvSIG installation.

• Use maven as a construction mechanism. There is a maven repository for gvSIG version 1.9. If you are able to prepare your project with maven then you should follow the multi-module structure recommended for the gvSIG 2 line.

  This is not essential and can be quite difficult if you aren't familiar with maven, but if you intend migrating to the gvSIG 2 line it is worth working towards.

• Keep the API implementation and the contributed features separate. Try to find a balance between a monolithic implementation and having several API and implementation libraries. Also try to ensure that dependencies between them are only through the API.

  If you want to start making the separation between the API and implementation in the 1.X code, you can use the mechanisms implemented in the org.gvsig.tools library for the gvSIG 2 line as these also work in the 1.X line.

• Keep the data access sections within the application's logic during implementation, and try as far as possible to keep track of those parts of the code that access data. When migrating to version 2.X these are the parts of the application that will have to be modified.

• Keep the access to controlled geometries in the logic part of the development. Changes in the handling of geometries are important in the 2.X line.

• Control and document which parts of the application are saved with the project. Data storage in the project has changed completely and you are now required to declare what will be stored in the project. It is therefore advisable to keep the data storage well-documented in order to faciliate the migration to 2.X projects.

• Use the slf4j API as a logging mechanism on the log4j backend. You can find more information on this in the document on Logging.

• Use the clonable interface. Use this interface when you have to clone objects and follow the java recommendations for doing so. Never use the project's persistence mechanisms for cloning an object. You can find more information on this in the document on cloning objects.

In general it is a good idea to read the sections on Creating a gvSIG project and Migrating projects to gvSIG 2.0 in the gvSIG 2.0 developers guide.

Al ejecutar la creación de un instalador, ya sea mediante la opción mvn create installer o mediante un comando similar a este desde la consola:

mvn -P create-installer install

es habitual encontrarse con un error que termina con líneas como estas:

[artifact:mvn] [INFO] Creating package of the package info:
[artifact:mvn] [INFO] org.gvsig.installer.lib.impl.DefaultPackageInfo@11e8050 (
[artifact:mvn]        code: org.gvsig.oracle
[artifact:mvn]        name: 
[artifact:mvn]        description: 
[artifact:mvn]        gvSIG-version: 
[artifact:mvn]        version: 0.0.1-0
[artifact:mvn]        buildNumber: 0
[artifact:mvn]        operating-system: all
[artifact:mvn]        architecture: all
[artifact:mvn]        java-version: j1_5
[artifact:mvn]        download-url: 
[artifact:mvn]        state: devel
[artifact:mvn]        official: false
[artifact:mvn]        type: unknow
[artifact:mvn]        model-version: 1.0.1
[artifact:mvn]        owner: 
[artifact:mvn]        owner-url: 
[artifact:mvn]        sources-url: 
[artifact:mvn]        dependencies: 
[artifact:mvn]        web-url: 
[artifact:mvn]        categories: [])
[artifact:mvn] [INFO] ------------------------------------------------------------------------
[artifact:mvn] [ERROR] FATAL ERROR
[artifact:mvn] [INFO] ------------------------------------------------------------------------
[artifact:mvn] [INFO] null
[artifact:mvn] [INFO] ------------------------------------------------------------------------
[artifact:mvn] [INFO] Trace
[artifact:mvn] java.lang.NullPointerException
[artifact:mvn]        at java.util.Hashtable.put(Hashtable.java:394)
[artifact:mvn]        at java.util.Properties.setProperty(Properties.java:143)
[artifact:mvn]        at org.gvsig.installer.lib.impl.info.InstallerInfoFileWriter.write(InstallerInfoFileWriter.java:101)
[artifact:mvn]        at org.gvsig.installer.lib.impl.info.InstallerInfoFileWriter.write(InstallerInfoFileWriter.java:74)
[artifact:mvn]        at org.gvsig.installer.lib.impl.info.InstallerInfoFileWriter.write(InstallerInfoFileWriter.java:59)
[artifact:mvn]        at org.gvsig.installer.lib.impl.DefaultInstallerProviderServices.writePackageInfoFile(DefaultInstallerProviderServices.java:148)
[artifact:mvn]        at org.gvsig.installer.lib.impl.DefaultInstallerProviderServices.writePackageInfoForIndex(DefaultInstallerProviderServices.java:136)
[artifact:mvn]        at org.gvsig.installer.lib.impl.creation.DefaultMakePluginPackageService.writePackageInfoForIndex(DefaultMakePluginPackageService.java:221)
[artifact:mvn]        at org.gvsig.installer.maven.GeneratePluginPackageIndexMojo.createPackage(GeneratePluginPackageIndexMojo.java:83)
[artifact:mvn]        at org.gvsig.installer.maven.AbstractGeneratePackageMojo.execute(AbstractGeneratePackageMojo.java:167)
[artifact:mvn]        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
[artifact:mvn]        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
[artifact:mvn]        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
[artifact:mvn]        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
[artifact:mvn]        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
[artifact:mvn]        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
[artifact:mvn]        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
[artifact:mvn]        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
[artifact:mvn]        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
[artifact:mvn]        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
[artifact:mvn]        at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
[artifact:mvn]        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[artifact:mvn]        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[artifact:mvn]        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[artifact:mvn]        at java.lang.reflect.Method.invoke(Method.java:597)
[artifact:mvn]        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[artifact:mvn]        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[artifact:mvn]        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[artifact:mvn]        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[artifact:mvn] [INFO] ------------------------------------------------------------------------
[artifact:mvn] [INFO] Total time: 11 seconds
[artifact:mvn] [INFO] Finished at: Fri May 11 15:34:48 CEST 2012
[artifact:mvn] [INFO] Final Memory: 57M/137M
[artifact:mvn] [INFO] ------------------------------------------------------------------------

BUILD FAILED
C:\dev\ew\gv2\build\ant-tasks\maven-goals.xml:35: The following error occurred while executing this line:
C:\dev\ew\gv2\build\ant-tasks\ant-tasks-config.xml:117: Java returned: 1

Esto suele ocurrir porque no se ha incluído una referencia al archivo package.info en distribution.xml. La solución consiste en añadir un párrafo similar a este en dicho archivo:

<assembly>
  ...
  <files>
  ...
      <file>
          <source>package.info</source>
          <outputDirectory>${extension.install.dir.name}
          </outputDirectory>
      </file>
  ...
  </files>    
  ...
</assembly>

Tras seguir los pasos descritos en el documento Cómo montar un workspace de gvSIG para Eclipse para montar un workspace completo de gvSIG, puede ocurrir que Eclipse nos señale mediante iconos de error algún problema de dependencias entre los diferentes proyectos. Esto ocurre aunque los scripts de ANT (mvn-eclipse-eclipse, mvn-install, etc) funcionan correctamente.

La causa podría ser un problema de comunicación entre Maven y Eclipse, que impide actualizar correctamente las dependencias de los proyectos en Eclipse.

El método conocido para solucionar esto consiste en comprobar en la pestaña Problems, qué proyectos tienen ese problema y usar el método mvn eclipse individualmente sobre cada uno de ellos, hasta eliminar todos los mensajes de error.

Tras montar el workspace de gvSIG tal como se indica en el documento Cómo montar un workspace de gvSIG para Eclipse, si intentamos ejecutar gvSIG desde el launcher de Eclipse, nos presenta un error diciendo que no puede encontrar el fichero ".../build/product/lib/...andami...jar" .

Si el proceso de descarga del workspace de gvSIG a terminado de forma satisfactoria esto puede deberse a que en el fichero $HOME/.m2/settings.xml esta especificada la ruta en la que hay que desplegar los plugins de gvSIG a una carpeta distinta a la de build/product de dentro del workspace de gvSIG. Esto es facil que ocurra si antes de montar el worlspace de gvSIG hemos estado trabajando con una instalacion de gvSIG generando plugins con el asistente para la generacion de plugins, en cuyo caso tendremos en el settings.xml la ruta a esa instalacion.

Para solucionarlo podremos hacer dos cosas:

• Editar el fichero $HOME/.m2/settings.xml y eliminar el profile en el que se define la propiedad "gvsig.install.dir"
• Editar el fichero $HOME/.m2/settings.xml y sustituir la ruta sustituyendola por la de la carpeta build/product del workspace de gvSIG.

Si vamos a estar trabajando tanto con el workspace de gvSIG como con el de algun otro plugin que estemos desarrollando sera recomendable la ultima opcion.