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