Crear un instalable de gvSIG
Preparación:
------------
Copiar a algún directorio, y meterlo en path, los scripts de python que se han dejado en el proyecto **install** del workspace (concretamente *install/scripts/svnScripts*). Estos scripts realizan en batch algunas tareas con el svn y nuestro workspace que veremos a continuación.
En el archivo svn-utils.py debemos sustituir en la linea 32 las cadenas "USUARIO" y "PASSWORD" por los valores correspondientes a nuestro usuario en el repositorio.
Pasos a seguir:
---------------
Nota: Los ejemplos se han puesto considerando que la versión de gvSIG cuyo instalador se va a generar es la 1.11.0. Si se va a generar un instalador de una versión posterior, sustitúyase donde aparezca 1.11.0 o 1_11_0 por la versión correspondiente. Si ha cambiado la versión de gvSIG, ahora solamente hay que cambiarla en el archivo *package.info* del proyecto **appgvSIG** en las propiedades *version* y *gvSIG-version*.
1.- Comunicar a la lista de desarrollo el número de versión y esperar un poco para que suban sus cambios (mirar en el archivo *build.number* de la extensión actual e incrementarlo en uno )
ejemplo::
Hola,
Se va a generar inmediatamente un nuevo build de gvSIG 1.11 para testing.
Este build se extraerá del Trunk.
Si tenéis algo pendiente, subidlo ya.
Saludos.
2.- Quitar el build automatically.
3.- Sincronización con el svn::
svn update *
4.- Hacer *clean-all* y *build all* del **build.xml** de **appgvSIG** para el workspace (a través de external tools).
5.- **Refresh** para todo el workspace.
6.- Comprobar que gvSIG arranca y carga lo que esperamos
7.- Ejecutar en consola de shell en el directorio del workspace::
svn update *
para descargar los cambios.
7.1.- Si no hay cambios (esto se mira en la ventana del shell), se pasa al siguiente punto.
7.2.- Si sí los hay, se hace **sincronize** y se bajan los cambios, y se repite todo desde el punto 4 (*clean all* y *build all*) hasta que en este punto no haya cambios.
8.- Ejecutar en consola de shell en el directorio del workspace::
svn-preparar_tag trunk pre_v1_11_0_Build_xxxx
donde xxxx es el el nuevo build number (indicado en el punto 1). Esto hace que se copien los proyectos desde el *trunk* al *tag/tmp_build/* (se realiza remotamente en el servidor sin hacer una copia en local).
9.- Cerrar eclipse
10.- Ejecutar en consola de shell en el directorio del workspace::
svn-sw_ToTmp_workspace
Esto hace un switch para cada uno de los proyectos a la nueva ubicación (*tag/tmp_build*).
11.- Hacer *clean-all* y *build all* del **build.xml** de **appgvSIG** para el workspace (a través de external tools). Comprobar que gvSIG arranca y carga lo que esperamos.
12.- Si hay que cambiar etiquetas de distribución (alpha, beta, RC1, ...) o número de versión cambiarlas en el::
install/instalador-gvSIG-lin/installer_files/LEEME (Aquí solo en caso de cambio de número de versión)
install/instalador-gvSIG-lin/installer_files/README (Aquí solo en caso de cambio de número de versión)
install/instalador-gvSIG-win/installer_files/LEEME.txt (Aquí solo en caso de cambio de número de versión)
install/instalador-gvSIG-win/installer_files/README.txt (Aquí solo en caso de cambio de número de versión)
install/build.properties (Aquí solo en caso de cambio de número de versión)
install/instalador-gvSIG-lin/install_template.xml (appname y appversion.
Hay que asegurarse de no dejar espacios y sustituirlos por guiones bajos)
install/instalador-gvSIG-win/install_15_template.xml (appname y appversion.
Hay que asegurarse de no dejar espacios y sustituirlos por guiones bajos)
_fwAndami/theme/andami-theme.xml (en dos sitios)
appgvSIG/package.info.
13.- Ahora desde external tools configurations ejecutamos el target *make-binary-distribution* del **build.xml** del proyecto **appgvSIG** . Esto hace que se incremente el build number de gvSIG.
14.- Comprobar que gvSIG arranca y carga lo que esperamos. Comprobar en el **about** de la aplicación que el build number es el que toca.
15.- Finalmente ejecutamos los siguientes targets del **build.xml** del proyecto **install**:
- check,
- linux* y
- windows*
NOTA:
Durante la ejecución de estos dos targets, el proceso se parará y mostrará un cuadro de dialogo con el texto "Instale en este momento las contribuciones externas y después continúe con este proceso. Cuando el instalador pregunte el lugar donde está instalado gvSIG, proporciónele la ruta al directorio prev_install que se ha creado nuevo en el directorio INSTALL de su workspace. ¿Desea continuar ahora?". Si queremos incoporar dichas contribuciones debemos hacerlo ahora:
- Si tenemos **paquetes de instalación para Linux** los ejecutamos (tanto si estamos ejecutando el target *"linux"* como el *"windows"*) y le suministramos (como dice el texto) la ruta al directorio *prev_install* del proyecto **install** del workspace.
- Si no, copiamos la extensión correspondiente al directorio *prev_install/bin/gvSIG/extensiones* que se ha creado nuevo en el directorio **install** de su workspace
Debemos asegurarnos de que se han copiado correctamente los ficheros *"package.info"* dentro de cada una de las extensiones incorporadas, y que el contenido de ellos es el que corresponde.
Para continuar con el proceso, seleccionamos "Sí" en el desplegable y pulsamos "OK".
Puede ser recomendable la ejecución de estos targets desde línea de comandos::
- ant -f build.xml check Linux
- ant -f build.xml check Windows
porque con las modificaciones que se han incorporado para la inclusión de las contribuciones externas, al ejecutarlos desde eclipse, se pierde la salida de la consola y no podremos ver si ha ocurrido algún error posterior a este punto.
16.- Se generan cuatro archivos, dos para *windows* y dos para *linux* (con y sin *jre*).
17.- Instalamos la aplicación para probarla y verificamos que la versión es la correcta (en el menú **help/about** tiene que figurar el nuevo build number).
18.- Si todo va bien subimos los archivos al servidor ftp de osor dentro de la carperta::
/home/groups/gvsig-desktop/www/downloads/pub/projects/gvSIG-desktop/devel/gvSIG-1_11/gvSIG-1_11_0/XXXX
donde XXXX es el nuevo build number (indicado en el punto 1)
19.- Si hemos cambiado etiquetas de distribución (*alpha, beta, etc.*) (pto. 12) habrá que subir estos cambios al tag en un solo commit.
20.- Cerrar eclipse.
21.- Ejecutar en consola de shell en el directorio del workspace::
svn-sw_workspace trunk
Esto hace un switch para cada uno de los proyectos a la ubicación original (*trunk*).
22.- Ejecutar en consola de shell en el directorio del workspace::
svn-merge_workspace_with_tmp_build
Esto hace un merge para cada uno de los proyectos a la ubicación original (*trunk*).
23.- Hacer commit en el trunk con los cambios que hemos hecho en el tag. El mensaje del commit será *v1_11_0_Build_xxxx* donde xxxx será el número de build
24.- Desde el svn explorer de eclipse u otra utilidad renombrar el tag *tmp_build* a *v1_11_0_Build_xxxx*. El mensaje del commit será *v1_11_0_Build_xxxx* donde xxxx será el número de build
25.- Crear un ticket de tipo nota en el bugtracking (tomar como *plantilla* anteriores tickets de este tipo, por ejemplo del build 1305 https://forge.osor.eu/tracker/index.php?func=detail&aid=15259&group_id=89&atid=804). No olvidar en el mismo comentario poner el enlace a las descargas de los binarios.