Personal tools
You are here: Home gvSIG Projects gvSIG Desktop Documentation Developers documentation gvSIG devel guide 1.11.0 Trabajar con el núcleo de gvSIG Crear un instalable de gvSIG
gvSIG Desktop
gvSIG Desktop

Cached time 11/21/13 17:14:03 Clear cache and reload

 
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.

View source document


Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: