Archive for 25 enero 2010

h1

Desactivar botón “Siguiente” en QWizard

25 enero 2010

En el trabajo estoy desarrollando una aplicación de escritorio que necesita generar una base de datos con Hibernate y los índices de los datos asociados para Hibernate Search, además de ciertas entradas mediante la API Preferences de Java. Como ejecutarlo mediante un script en una aplicación de escritorio da una apariencia un poco cutre 🙂 decidí crear un instalador mediante la clase QWizard de QtJambi. En una de las pantallas se mostraba la típica lista de avances y quería desactivar el botón Siguiente hasta que terminase el proceso. Al principio pensé que mediante el método setEnabled(false) del botón sería suficiente pero no surtía ningún efecto, la solución final es más o menos igual de sencilla: reimplementar el método QWizardPage.isComplete() fijando su retorno mediante una variable booleana. En resumen:

class InstallPage extends QWizardPage {
    private boolean complete;

    @Override
    public boolean isComplete() {
        return complete;
    }

    public void install() {
        // ejecutar los pasos de la instalación
        complete = true;
    }
}

Para volver a activar el botón, en este caso sí funciona el método setEnabled(true).

Anuncios
h1

Communicating Mantis and Subversion on Windows

7 enero 2010

Although this blog is mainly written in Spanish, because of the lack of information both in Spanish and English, I’ll try to explain how to communicate Mantis and Subversion on a Windows server. Please be gentle with my English, but feel free to send any correction 🙂

Installing Mantis and Subversion (it’s logical)

I think it’s not that hard, otherwise there are lots of tutorials out there in the net 😉 In my case, I used the CollabNet svnserve package, which automatically creates a repositories folder in C:\svn_repositories and the corresponding Windows service. We must also create a repository, in my case in C:\svn_repositories\repositorio-1 (originality for the win!).

Creating a Mantis user account

This account (something like “svn”) should be able to add messages to the tickets and (optionally) close them. It is enough to grant it the developer role. Note: Don’t forget to assign it to the projects where this task is going to be automated!

Editing the config_inc.php file

It is placed in the Mantis root folder. The changes to this file include the user account created in the previous point, the regular expressions to match in order to identify a message which references an issue and, if we want the tickets to be automatically marked as resolved, another regexp, the final status and the resolution. It will be something like this:

# User account that connects with Subversion
$g_source_control_account = 'svn';

# Regular expression to be matched in the comments
# Example: issue #1
$g_source_control_regexp = '/\b(?:bug|issue|error)\s*[#]{0,1}(\d+)\b/i';

# Regular expression to be matched to fix an issue
# Example: fixed issue #1
$g_source_control_fixed_regexp = '/\b(?:fixed|fixes|resolved)\s+(?:bug|issue|error)?\s*[#](\d+)\b/i';
# Status after solving the issue
$g_source_control_set_status_to = RESOLVED;
# Resolution after solving the issue
$g_source_control_set_resolution_to = FIXED;

First test

We will need some things in order to perform an initial test:

  1. Creating a dummy issue in Mantis and remember its number 🙂
  2. Creating a text file which contains a dummy commit message like “fixed issue #1” (this is why we needed the issue number).
  3. Accessing to a system shell, like using remote desktop (why not native SSH?). Once it is open, since Windows’ standard input sucks and we can’t input the text directly with the <<< operator, we run the command
    C:\path\to\php.exe C:\path\to\mantis\scripts\checkin.php < C:\path\to\text\file
    If the contents of the text file don’t match the regexp, we will get the message “Comment does not reference any issues”, otherwise the status of the Mantis issue should have changed to “resolved”, and a comment with the text should have been appended to the ticket. Don’t forget that some Mantis versions (this should be fixed for 1.2 final) only accept one-line messages; if they have more than one line they won’t be related to any issue.

Connecting the Subversion server

Once we have checked the basics, we’re going to connect Mantis with the Subversion server, for which we will use a BAT file that will run after every commit, which is called a SVN hook (there are also pre-commit, pre/post-update hooks, etc.). This file must be placed in the hooks folder of the repository, i.e. C:\svn_repositories\repositorio-1\hooks, and named post-commit.bat.
Its contents will be as follows, without forgetting to change the PHP, CHECKIN and SVNLOOK variables paths to the correct ones in your system:

@ECHO on

SET REPOS=%1
SET REV=%2

SET PHP="C:\Program Files\PHP\php.exe"
SET CHECKIN="C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\mantis\scripts\checkin.php"
SET SVNLOOK="C:\Program Files\CollabNet\Subversion Server\svnlook.exe"

SET LOGFILE=C:\Temp\log.txt
SET AUTHORFILE=C:\Temp\author.txt
SET OUTPUTFILE=C:\Temp\output.txt

%SVNLOOK% log -r %REV% %REPOS% > %LOGFILE%
%SVNLOOK% author -r %REV% %REPOS% > %AUTHORFILE%

TYPE %LOGFILE% > %OUTPUTFILE%

%PHP% %CHECKIN% < %OUTPUTFILE% >> %LOGFILE%
ECHO "Post-commit for revision %REV% finished" >> %LOGFILE%

@ECHO off

Once the file is placed in the folder, we must restart the SVN server in order to register it (I spent a lot of time with this stupidity).
As result, there should be a text file C:\temp\output.txt with the SVN log for the last revision, and another C:\temp\log.txt with the log, the checkin.php output (empty) and the text string confirming the post-commit execution. Oddly, if I didn’t include this last output the script exited with a 255 error and no output, but the Mantis ticket was correctly modified; so it is there just to avoid confusing the user. If someone knows a possible reason for this one, I would be glad to read comments about it 😀

h1

Comunicar Mantis y Subversion en Windows

7 enero 2010

Para empezar bien el año, en el trabajo me tocó una tarea de administración, consistente en comunicar nuestro servidor Subversion para desarrollo con el bugtracker Mantis, para que cuando se hiciese un commit con un mensaje de la forma “arreglada incidencia #1” se marcase automáticamente como resuelta en este último 🙂
Desgraciadamente era sobre un servidor Windows y toda la información vi en Internet hace referencia a servidores Linux (excepto un script post-commit de SVN que no funcionaba xD) así que, para aquellos que lo vayan a sufrir en el futuro, espero que les sirva de guía. Los pasos son los siguientes:

Instalar Mantis y Subversion (lógico)

Espero que esto no suponga ninguna dificultad, si no hay 3000 tutoriales por la red 😉 En mi caso, para el servidor de SVN utilicé el paquete de CollabNet, que crea automáticamente una carpeta para repositorios en C:\svn_repositories y el servicio de Windows asociado. También tenemos que crear un repositorio, en mi caso en C:\svn_repositories\repositorio-1 (originalidad al poder).

Crear una cuenta de usuario de Mantis

Dicha cuenta (por ejemplo “svn”) debe poder añadir mensajes a las incidencias y (opcionalmente) cerrarlas. Con asignarle el nivel de desarrollador es suficiente. Nota importante: ¡No olvidar asignarle los proyectos donde se quieran automatizar esta tarea!

Editar el archivo config_inc.php

Se encuentra en el directorio raíz de Mantis. Los cambios incluirán la cuenta creada en el punto 2, las expresiones regulares por las que se identifica que un mensaje se refiere a una incidencia y, si vamos a permitir que las marque automáticamente como resueltas, el estado y la resolución a las que se haya llegado. Serían algo tal que así:

# Cuenta que se conecta con Subversion
$g_source_control_account = 'svn';

# Expresión regular a encajar en los comentarios
# Ejemplo: incidencia #1
$g_source_control_regexp = '/\b(?:bug|issue|incidencia|fallo|error|problema)\s*[#]{0,1}(\d+)\b/i';

# Expresión regular a encajar para resolver una incidencia
# Ejemplo: resuelta incidencia #1
$g_source_control_fixed_regexp = '/\b(?:resuelto|resuelta|arreglado|arreglada|corregido|corregida)\s+(?:bug|issue|incidencia|fallo|error|problema)?\s*[#](\d+)\b/i';
# Estado tras resolver la incidencia: resuelta
$g_source_control_set_status_to = RESOLVED;
# Resolución trasresolver la incidencia: corregida
$g_source_control_set_resolution_to = FIXED;

Primera prueba

Para hacer una prueba inicial de su funcionamiento necesitaremos varias cosas:

  1. Crear una incidencia de prueba en el Mantis y acordarnos de su número 🙂
  2. Crear un archivo de texto que contenga un falso mensaje de commit como “resuelta incidencia #1” (para esto era importante acordarse).
  3. Acceder de alguna forma a una consola del sistema, por ejemplo, conectándonos por escritorio remoto (¿por qué no SSH nativo?). Una vez en ella, como la entrada estándar de Windows apesta y no podemos introducir el texto directamente con el operador <<<, ejecutamos la orden
    C:\ruta\a\php.exe C:\ruta\a\mantis\scripts\checkin.php < C:\ruta\al\archivo\del\mensaje
    Si no encaja con la expresión regular, obtendremos un mensaje “Comment does not reference any issues” (“El comentario no hace referencia a ninguna incidencia”). En caso contrario, abrimos la incidencia en el Mantis y su estado debería haberse modificado, y haberse añadido el mensaje con el texto. Es importante tener en cuenta que en ciertas versiones de Mantis (para la final de 1.2 ya debería estar corregido) en esta situación solo se aceptan mensajes de una línea; si tiene varias no lo asociará a una incidencia.

Conexión con el servidor Subversion

Una vez comprobado que lo básico no explota, pasamos a conectarlo con el servidor Subversion. Para ello utilizaremos un archivo BAT que se ejecutará después de cada commit, lo que se denomina un hook de SVN (también hay hooks para antes de un commit, de un update, etc.). Este archivo debe guardarse en la carpeta hooks del repositorio, en mi caso en C:\svn_repositories\repositorio-1\hooks, con el nombre post-commit.bat.
El contenido del archivo será tal que así, sin olvidar sustituir las rutas de las variables PHP, CHECKIN y SVNLOOK a lo que correponda en el sistema de cada uno:

@ECHO on

SET REPOS=%1
SET REV=%2

SET PHP="C:\Program Files\PHP\php.exe"
SET CHECKIN="C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\mantis\scripts\checkin.php"
SET SVNLOOK="C:\Program Files\CollabNet\Subversion Server\svnlook.exe"

SET LOGFILE=C:\Temp\log.txt
SET AUTHORFILE=C:\Temp\author.txt
SET OUTPUTFILE=C:\Temp\output.txt

%SVNLOOK% log -r %REV% %REPOS% > %LOGFILE%
%SVNLOOK% author -r %REV% %REPOS% > %AUTHORFILE%

TYPE %LOGFILE% > %OUTPUTFILE%

%PHP% %CHECKIN% < %OUTPUTFILE% >> %LOGFILE%
ECHO "Ejecutado post-commit de revisión %REV%" >> %LOGFILE%

@ECHO off

Tras copiar este archivo en la carpeta, debemos acordarnos de reiniciar el servidor SVN para que lo registre (perdí mucho tiempo por culpa de esto).
Como resultado, deberíamos obtener un archivo en C:\temp\output.txt con la salida del log de SVN para la última revisión, y otro en C:\temp\log.txt con, además de esta, la de checkin.php (vacía) y la cadena de confirmación de ejecución del post-commit. Extrañamente, si no incluía esta última salida el script terminaba con un error 255 sin ninguna salida, pero sin embargo la incidencia del Mantis se modificaba correctamente; simplemente está para evitar confundir al usuario. Si alguien sabe a qué puede deberse esto estaré encantada de leer comentarios al respecto 😀

h1

Fin de la importación

6 enero 2010

Finalmente no ha sido tan traumático, con solo algunos conflictos en las categorías, ya he importado todos los mensajes del blog anterior y eliminado aquellos que me parecieron algo obsoletos, espero que los restantes le sirvan de ayuda a alguien. A partir de ahora todo lo que publique será original, único, exclusivo 8) y con una antigüedad de menos de medio año xD

h1

QtJambi y JUnit (UnsatisfiedLinkError)

6 enero 2010

En el trabajo estoy desarrollando una aplicación con QtJambi, y además de la interfaz, parte del núcleo hace uso de ello para enviar señales con notificaciones de progreso al procesar unos archivos. Al intentar pasar las pruebas de JUnit sobre esta parte recibía siempre la misma excepción:

Exception in thread "main" java.lang.UnsatisfiedLinkError: com.trolltech.qt.internal.QtJambiInternal.fetchSignal(Lcom/trolltech/qt/internal/QSignalEmitterInternal;Ljava/lang/reflect/Field;)Lcom/trolltech/qt/internal/QSignalEmitterInternal$AbstractSignalInternal;

En la lista de correo de QtJambi descubrí algo que debía ser evidente: antes de lanzar las pruebas debía invocar a QApplication.initialize(new String[]{}) (se crea un nuevo array porque no se reciben parámetros explícitos a través de un main). Incluyendo esto en el método setUpBeforeClass ya funcionó todo perfectamente.

h1

Ejecutar Grim Fandango en Windows XP SP3

6 enero 2010

¡Hora y media es lo que tardé en poner a funcionar la nueva edición de Grim Fandango en XP! Y eso que ya sabía a lo que me enfrentaba y me habían dado ciertas pistas. Como primer aviso para aquellos que estén tan desesperados como yo lo estaba, conste que este post implica un proceso de instalación completo, aunque si no se puede jugar de otra forma no creo que le importe a nadie xD

El primer paso es descargarse el instalador/lanzador no-oficial, una maravilla que permite instalar el juego en operativos de 64 bits, lanzar el juego a pantalla completa o en ventana, ejecutar el modo depuración o cargar el juego desde disco duro sin necesidad de los CDs. Muchísimas gracias al autor *_*

Una vez instalado el juego, si ejecutamos el lanzador irá a descargar el último parche del juego del FTP de LucasArts (que resolvía algunos problemas de cuelgues en puzzles), pero a mí por lo menos no me conseguía conectar a pesar de desbloquearlo en el firewall de XP. De todas formas, en Grim Fandango Network tienen un enlace a él. Gracias a vosotros también *_*

Aplicamos el parche, activamos el modo compatibilidad de Windows a Windows 98/ME, ejecutamos el lanzador y seleccionamos la opción de lanzar el juego desde disco duro (por lo que comentan parece ser más estable y evidentemente más rápido). Ahora sí que lo ejecutamos a pantalla completa, pero si nuestra tarjeta gráfica no es de antes del Pleistoceno probablemente los gráficos y el audio sí que lo parezcan: Manny aparecerá como un código de barras y quizá ni oigamos nada. La solución la encontré en el blog Proyecto QWERTY (hoy no me canso de dar las gracias), y consiste en ejecutar el dxdiag.exe en la carpeta donde tengamos instalado el juego; probablemente lance un error, esto que recuerde lleva pasando toda la vida xD En la pestaña Display 1 desactivamos DirectDraw y salimos de la aplicación. Al volver al juego ya funcionará bien, ¡aleluya!

h1

JDOM no encuentra la DTD de un XML

6 enero 2010

Al parsear un fichero XML con JDOM no es difícil descubrir que no encuentra la ruta a la DTD con que se valida, especialmente con la directiva SYSTEM dentro del DOCTYPE.

En este caso, JDOM lanza una FileNotFoundException pero, si no se quiere buscar dicho fichero, se debe implementar un EntityResolver (el encargado de interpretar las entidades definidas en dicha DTD) que no haga nada.

El código resultante sería algo similar a lo siguiente:

SAXBuilder builder = new SAXBuilder();

// Dummy EntityResolver
builder.setEntityResolver(new EntityResolver() {
    public InputSource resolveEntity(
           String publicId, String systemId) 
           throws SAXException, IOException {
        return new InputSource(new StringReader(" "));
    }
});

doc = builder.build(...);