Vamos a describir los pasos que se siguen actualmente para generar una distribución de fuentes de la aplicación gvSIG. Al tener gvSIG una licencia GPL se deben distribuir los fuentes para quienes quieran descargarlos, pero éstos no se generan para cada distribución que se genere, debido a que demanda un trabajo bastante laborioso, por lo que se deberán generar cada vez que tengamos una distribución de binarios definitiva.

Debido a que la generación requiere que el fichero zip resultado contenga enlaces simbólicos (para minimizar el tamaño del fichero), se necesita hacer este proceso en una maquina con FileSystem con soporte para ello, osea Linux/Unix.

También requerimos (hasta nuevo aviso) un Eclipse v3.1 para mantener la máxima compatibilidad con las versiones de este IDE.

Lo primero de todo es crear un nuevo workspace, y su nombre debe seguir el esquema “gvSIG-VERSION-src”, por ejemplo "gvSIG-1_1-src". Se tendrán que incluir los proyectos de la lista que se pueden encontrar el la página de la versión (normalmente dentro de proyectos-que-la-componen/proyectos-de-la-version/).

También hay que tener en cuenta que el proyecto install no se distribuye.

Ahora, desconectamos todos los proyectos del SVN (seleccionamos todos los proyectos y TEAM->DISCONNECT) y borramos el .metadata del workspace. Volvemos a abrir el Workspace pero usando el Eclipse 3.1 e importamos todos los proyectos usando la opción File/Import.../Existing Projects into workspace/Next/Browse/Ok/Finish.

El proyecto “binaries” contiene las librerías nativas para Windows, Linux y Mac OSX. Sin embargo, no hay que incluirlo tal cual, ya que las librerías no son usables tal cual están en el SVN. Hay que incluirlo con una distribución de archivos similar a la que tiene el directorio “libs” de una instalación de gvSIG. Más abajo veremos como hacerlo.

Es necesario configurar Eclipse para asegurar que compilará en cualquier entorno:

Window ⇒ Preferences ⇒ General ⇒ Editors ⇒ Text file encoding ⇒ Other (ISO-8859-1)

Window ⇒ Preferences ⇒ Java ⇒ Compiler ⇒

  * Compiler compliance settings: 5.0
  * Desmarcar “Use default compliance settings”
  * Marcar “Generated .class file compatibility”: 1.5
  * Marcar “Source compatibility”: 1.4

Se debe crear una configuración de ejecución (Run) de Eclipse, para que una vez ejecutados los builds, podamos ejecutarla correctamente. Esta configuración se puede copiar de una versión anterior de los fuentes (directorio .metadata/.plugins/org.eclipse.debug.core/.launches) o hacer a mano. En la configuración se debe incluir los parámetros adecuados de Java (incluido el -Djava.library.path y la variable de entorno LD_LIBRARY_PATH. Las rutas asignadas a estas variables deben ser relativas, no absolutas, para que funcionen independientemente de dónde se deje caer el workspace.

Se creara una configuración de ejecución para cada Sistema Operativo,los parámetros son los siguientes:

• Pestaña Main: Project="_fwAndami", Main class="com.iver.andami.Launcher"
• Pestaña Arguments:
  • Program arguments: "gvSIG gvSIG/extensiones"
  • VM arguments:
    • Para linux: "-Xmx500M -Djava.library.path=${workspace_loc}/binaries/linux"
    • Para windows: "-Xmx500M -Djava.library.path=${workspace_loc}/binaries/w32"
    • Para MacOS X: "-Xmx500M -Djava.library.path="${workspace_loc}"/binaries/mac"
• Pestaña Environment:
  • Para TODOS: "PROJ_LIB" => "${workspace_loc}/_fwAndami/gvSIG/extensiones/org.gvsig.crs/data".
  • Para linux: "LD_LIBRARY_PATH" => "${workspace_loc}/binaries/linux".
  • Para windows: "PATH" => "${workspace_loc}/binaries/w32".
  • Para MacOS X: "DYLD_LIBRARY_PATH" => "${workspace_loc}/binaries/mac".

Se debe compilar el workspace y ejecutar todos los builds en el orden correcto(se pueden usar los targets clean all y build all del build.xml de appgvSIG), y posteriormente ejecutar gvSIG, para comprobar que compila sin problemas y produce un gvSIG que funciona correctamente.

También hay que configurar un External Tool (menu Run-> External Tools -> External Tools) para que se pueda reconstruir el workspace. Para ello tendremos que seguir los siguientes pasos:

• Lanzar build.xml del proyecto appgvSIG usando el botón derecho sobre el fichero Run As/ Ant build. Esto nos generará un External Tools llamado appgvSIG build.xml.
• Desde el menú de External Tools, duplicar la definición appgvSIG build.xml y cambiarle el nombre a Build All.
• Modificar el target que lanzará por el de "eclipse-build-all".
• Desmarcar la opción Build befor lanuch de la pestaña Build.
• Marcar la opción Refresh resorces upon completion de la pestaña Refresh.

Es necesario dejar el External Tools llamado appgvSIG build.xml ya que sino, el eclipse siempre lanzaría el Build all por defecto al ejecutar el build.xml de appgvSIG.

Una vez comprobado que todo funciona correctamente, empezamos a limpiar el workspace. Lo primero sera limpiar el directorio de binaries. Para prepararlo seguiremos los siguientes pasos:

• Dentro del directorio binaries ejecutar el target a usar se llama build-all.
• Revisar los enlaces del directorio biniaries/linux de crs. (Deberían de copiar los fichero a binaries/linux y revisar los enlaces simbólicos).
• Eliminar los subdirectorios de cada S.0
• Eliminar el directorio binaries/ant

También se deben borrar algunos ficheros y directorios que no se desea incluir.Estos se deben borrar desde dentro del eclipse, ya que al borrar algunos de esos directorios desde fuera de Eclipse se vuelve un poco loco. Por tanto, desde dentro de Eclipse vamos borrando los ficheros y directorios siguiendo los siguientes pasos:

• Renombrar el proyecto libUI_Components_praster a libUI_Components y modificar el nombre del proyecto en appgvSIG/build.xml.
• Desactivar la opción compilación automática en el menú Project ⇒ Build Automatically.
• Lanzar el target clean-all del build.xml del proyecto appgvSIG.
• Recorrer todos los proyectos y borrar todas las subcarpetas: doc, test, src-test, bin-test, install (En los proyectos lib_UI, libUIComponent_praster y libDwg no borrar la carpeta doc sino solo su contenido y no tocar el src-test del libGDBMS).
• En el proyecto libGDBMS borrar también la carpeta conf y el fichero notas.txt.
• En el proyecto libInternationalization borrar también las carpetas: src-utils, test-data, utils-data y bin-utils.
• En el proyecto appCatalogAndGazetteer borrar también las carpetas: design, documents y servers.
• En el proyecto _fwAndami borrar también los ficheros: gvSIG.sh, gvSIG.bat y "por hacer.txt".
• Hacer un clean de los proyectos (menú Project ⇒ Clean, desactivar el check de Start a build... con la opción seleccionada Clean all proyects)
• En los proyectos libJCrs y extJDBC borrar también la carpeta dist.
• En el proyecto extOracleSpatial la carpeta dist y el contenido de la carpeta lib (incluido el _save, ya que no tenemos permisos para distribuir los *.jar de Oracle).
• Borrar los directorio _fwAndami/gvSIG y _fwAndami/cachedir
• Del proyecto libJCRS quitar en las propiedades del proyecto Builders / crsgdal build.xml [Builder].

Ahora vamos a dejar el workspace configurado de la forma en que se la tiene que encontrar el usuario cuando lo abra. Es importante que dejemos abierto el fichero appgvSIG/build.xml en el editor, ya que el eclipse tiene un bug que nos podría dejar corrupto el External Tool que acabamos de crear. Dejaremos solo la perspectiva Java abierta. Comprobamos que están los Run y External Tool definidos y que la opción del menú Proyect ⇒ Build Automatically esta desmarcada. Cerramos el Eclipse y no lo volvemos a abrir en este workspace.

Ahora procedemos a borrar algunas librerías redundantes y ficheros que sobran. Esto se debe hacer desde fuera del Eclipse porque provoca que algunos proyectos no compilen inicialmente, pero esto se resolverá conforme el usuario final lance los proyectos en el orden especificado:

rm libFMap/lib/geojava.jar libFMap/lib/geotiff-jai.jar 
rm libFMap/lib/jecw-*.jar libFMap/lib/jecwcompress-*.jar 
rm libFMap/lib/jgdal-*.jar libFMap/lib/jmgeoraster.jar  
rm libFMap/lib/jmrsid-*.jar libFMap/lib/jogr.jar 
rm libFMap/lib/kxml2.jar libFMap/lib/tar.jar 
rm libFMap/lib/remote-clients.jar libFMap/lib/cms.jar 
rm libFMap/lib/gt2-legacy.jar libFMap/lib/gt2-main.jar 
rm libFMap/lib/fmap.jar libFMap/lib/ojdbc14.jar 
rm libFMap/lib/jGridShiftApi.jar libFMap/lib/geoapi-2.0.jar 
rm libFMap/lib/log4j*.jar libFMap/lib/tempFileManager.jar
rm _fwAndami/lib/gvsig-i18n.jar _fwAndami/lib/iver-utiles.jar

Finalmente, se pueden borrar algunos ficheros en el directorio .metadata del workspace, que ocupan mucho espacio (esto sería conveniente hacerlo con el Eclipse cerrado). Desde la consola:

rm .metadata/.plugins/org.eclipse.jdt.core/*.index
rm .metadata/.plugins/org.eclipse.jdt.core/savedIndexNames.txt
touch .metadata/.plugins/org.eclipse.jdt.core/savedIndexNames.txt
rm -R .metadata/.plugins/org.eclipse.core.resources/.history/*
rm .metadata/.plugins/org.eclipse.debug.ui/launchConfigurationHistory.xml
find . -name .classpath -exec touch {} ';'

Lo último que quedaría por hacer es el empaquetado. Se debe añadir algunos ficheros build.xml y LEEME en la raíz del Workspace. Desempaquetar unas fuentes anteriores y copiar los ficheros faltantes. Hay que revisar los distintos LEEME y revisar si las instrucciones siguen siendo correctas. Actualizar los números de versión y los proyectos a compilar.

Los fuentes se empaquetan en un fichero ZIP. Normalmente siguen la nomenclatura gvSIG-VERSION-src.zip, por ejemplo “gvSIG-1_1-src.zip”. El fichero zip se debe generar de forma que se respeten los enlaces simbólicos (en caso contrario algunas librerías se copiarían por duplicado y ocuparían mucho espacio). En Linux, para ello usamos el comando:

zip -y9r gvSIG-1_1-src.zip gvSIG-1_1-src

Actualmente se genera un único fichero tanto para Linux como para Windows. Se está valorando crear dos ficheros diferentes, para hacer más ligera su descarga (ya que no sería necesario incluir las librerías de un sistema en el otro).