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.