En sidelab colaboramos habitualmente con grupos de investigación, empresas tecnológicas, etc. El pasado Miércoles 18 de Noviembre se emitió en Telemadrid una entrevista en la que se presenta el Ciberguardián, un sistema que detecta los casos de acoso en las redes sociales Facebook y Tuenti. Este sistema ha sido desarrollado por Luis López (Subdirector de la Escuela Técnica Superior de Ingeniería de Telecomunicación de la URJC) y yo, Micael Gallego, miembro de sidelab y profesor del Departamento de Ciencias de la Computación de la URJC. También ha colaborado con nosotros David Sevillano, un alumno que hizo su proyecto de fin de carrera en el Ciberguardián.
Como véis, Java y Eclipse salen todo el rato en la entrevista. Al cámara le gustaron todas esas ventanitas, colores y código fuente que aparecía y se movía por la pantalla, así que estuvimos un buen rato moviendo el ratón de un lado para otro 🙂
Acabo de instalar Ubuntu 9.10. Ya comentaré lo que funciona y lo que no funciona en mi portátil (HP dv3550es), pero esta entrada viene motivada por otra cosa. Una de las primeras acciones siempre que reinstalo Ubuntu es bajarme la última versión de eclipse. Cuando tengo Eclipse funcionando, ya puedo respirar tranquilo (incluso aunque tenga que pasarme sin muchas otras cosas hasta que tenga tiempo de solucionarlas).
En esta ocasión me instalo Eclipse 3.5.1. Concretamente me bajo el paquete Classic. Este paquete viene ya con PDE y el código fuente de la plataforma y de JDT, con lo que te sitúa en buena disposición a la hora de realizar plug-ins. Lo arranco sobre un workspace nuevo, por no tener problemas con recursos que dependen de plug-ins aún no instalados. Inmediatamente, me pongo a instalar los plug-ins que necesito. Marco algunos de la categoría Modeling (UML2 y OCL para un proyecto en el que estamos trabajando), CDT, Ruby (para una de las asignaturas que impartimos), Subversive y Mylyn.
Voy a pulsar el botón Next para continuar una vez seleccionados los que necesito del repositorio de Galileo, y me sorprendo al ver que el botón se pulsa, sí, pero se queda pulsado. Y no realiza ninguna acción. Pruebo a darle al enter, y entonces sí reacciona. Voy utilizando el enter para ir pasando de una ventana a otra hasta dejar mi Eclipse instalando lo que le he dicho.
Entonces me pongo a buscar quién se ha encontrado el mismo error. Rápidamente me encuentro con alguna entrada donde se comenta el problema. Se trata de un problema en Ubuntu 9.10 Karmic Koala debido a la versión de GTK que incluye esta nueva versión (GTK 2.18). No es que GTK tenga un bug ni nada parecido. Simplemente han cambiado el modo de gestionar ventanas hijas de la aplicación, pero la versión SWT de Eclipse 3.5 no fue pensada con esta nueva característica en mente. El resultado es un comportamiento de SWT erróneo con esta versión de GTK.
En este bug se comenta en detalle el problema. En la versión 3.6M3 ya está solucionado (acabo de descargarlo y probarlo). Estará también solucionado en 3.5.2 y en la próxima versión de mantenimiento (parece que para la próxima semana, porque la de esta semana aún no funciona). Mientras tanto el problema puede solventarse arrancando Eclipse desde un script que contenga lo siguiente:
En otras páginas he visto true en la variable de entorno en lugar de 1.
Cuando mi Eclipse termina de instalar, lo cierro, me creo el script y lo lanzo desde ahí (yo además le tengo que pasar el bin del jdk de 64 bits con la opción -vm). Observo que los botones funcionan, pero el aspecto está raro:
¿Qué ves extraño en esta imagen?
La respuesta está en el espacio a la izquierda de las diferentes opciones del menú: no aparecen los iconos. Por lo visto en Ubuntu 9.10 se puede especificar que no se muestren los iconos en los menús. En mi caso era un poco raro, porque en los menús Aplicaciones y Lugares se mostraban, pero no en Sistema. En Sistema>Preferencias>Apariencia, en la pestaña Interfaz, marcando la casilla Mostrar iconos en los menús, todo vuelve a la normalidad.
Cuando estoy desarrollando plug-ins, de vez en cuando me sucede que necesito hacer algo tan simple como mostrar un diálogo y suelo caer casi siempre en el mismo error. Supongamos el siguiente ejemplo:
MessageBox mb = new MessageBox(plugin.getWorkbench().getActiveWorkbenchWindow().getShell(), SWT.OK);
mb.setMessage(message);
mb.setText("Launching...");
mb.open();
Este código lo tengo en un plug-in que contribuye a la interfaz de usuario. Cuando lo ejecuto, obtengo NullPointerException. Al depurar, veo que getActiveWorkbenchWindow devuelve null. La documentación de este método especifica:
Returns null if called from a non-UI thread.
El problema es que no puedo ejecutar este método si no estoy en el UI thread. Si depuramos la ejecución podemos ver que no se está ejecutando en el hilo de despacho de eventos:
Para ejecutar código que necesita acceder a la UI (como mostrar un cuadro de diálogo) tenemos dos alternativas: Display.asyncExec(Runnable) y UIJob. La primera ejecuta un objeto Runnable en el hilo de eventos en cuanto tenga una oportunidad. No es bloqueante y no se avisa al que invoca asyncExec cuando la tarea termina.
UIJob es más versátil, permite utilizar prioridades para definir la prioridad de las diferentes tareas, permite avisar al que especificó la tarea (mediante UIJob.addJobChangeListeners) y se pueden especificar políticas de planificación en caso de que esta tarea no pueda ejecutarse concurrentemente con tareas en otros hilos.
La forma de utilizar UIJob es simplemente crear un objeto, implementar el método runInUIThread(IProgressMonitor) y finalmente invocar el método UIJob.schedule() para dejar la tarea encolada en el hilo de despacho de eventos:
UIJob uijob = new UIJob("Launching...") {
@Override
public IStatus runInUIThread(IProgressMonitor monitor) {
MessageBox mb = new MessageBox(plugin.getWorkbench().getActiveWorkbenchWindow().getShell(), SWT.OK);
mb.setMessage(message);
mb.setText("Launching...");
mb.open();
return Status.OK_STATUS;
}
};
uijob.schedule();
Ahora nuestra tarea se ejecuta en el hilo adecuado (Main es el hilo de despacho de eventos):
Sidelab se congratula de anunciar (mala traducción de «sidelab is pleased to announce…») que vamos a dar una charla sobre Mylyn en la Universidad Rey Juan Carlos el 3 de Noviembre (mañana) a las 12:00 en el laboratorio 103 del Departamental II del Campus de Móstoles.
Así en general se podría decir que Mylyn es un plugin de Eclipse que permite integrar Eclipse, Bugzilla y Subversion. Y si entramos un poco más en detalle vemos que en realidad se puede integrar con cualquier gestor de tareas (Bugzilla, Trac, JIRA, Sourceforge, Google Code, etc…). Además, también tiene integración con CVS y posiblemente muchos otros gestores de código (Git, Mercurial, etc…).
Pero una de las características más relevantes de Mylyn es lo que se denomina task focused interface, que filtra aquellos elementos (clases, métodos, atributos) que no son relevantes para la tarea que se está realizando. Esto permite «focalizar» y centrarse en la tarea actual y no perderse entre las decenas de proyectos del workspace, los cientos de clases de cada proyecto y las decenas de métodos de cada clase…
Esta charla tiene su página con toda la información relevante (presentación, demo, links de interés,…). Para los perezosos… podéis descargar la presentación de Mylyn directamente.
Boris Bokowski, committer del proyecto Platform UI de Eclipse, ha escrito un post que ha sido,sin duda, el que más claro me ha dejado hacia dónde vamos con e4. En el artículo, Boris explica, paso por paso, cómo adaptar el editor de PDE (Platform Development Environment) para el fichero plugin.xml a e4.
La verdad es que hasta la fecha me había mantenido relativamente al margen del desarrollo web, salvo por alguna incursión rápida de la que salía bastante escaldado y dispuesto a no volver. Esto ha hecho que me haya mantenido en un prudente segundo plano en lo que al desarrollo web se refiere. He mantenido cierto interés «intelectual», en el sentido de conocer por dónde andaban los tiros, pero no me he remangado hasta los codos para ponerme manos a la obra.
Sin embargo, es evidente que cada vez tengo menos argumentos si no quiero quedarme fuera de juego. Por un lado, AJAX ha hecho que las aplicaciones web no tengan nada que envidiar a las aplicaciones de escritorio, con todas las ventajas añadidas de estar en la web. Por otro lado, la información poco a poco va pasando de nuestros equipos a la web, a través de Facebooks, Flickrs, Readers, Blogs y demás familia. Pero ya lo último es el enfoque de Eclipse para e4. La web del proyecto e4 (en fase incubator) dice:
The mission of the e4 project is to build a next generation platform for pervasive, component-based applications and tools
Y un poco más adelante se puede leer:
These trend lines point to web technologies, new user interface metaphors, and distributed infrastructure.
Así que he decidido probar e4. Y para ello he utilizado el ejemplo e4photo. Con un poco de css, uno puede cambiar rápidament el aspecto de la interfaz (la aplicación no tiene manera de refrescarse con el nuevo contenido del css, así que hay que pararla y volverla a arrancar):
Desde luego el aspecto no es muy agradable. Pero da igual, porque lo puedes cambiar tocando el css. Así que habrá que ponerse a hacer skins para Eclipse.
Update: Se me olvidaba comentar los cambios respecto a la versión original: el fondo de la vista Library es gris en lugar de blanco, los títulos de las pestañas granates en lugar de naranjas, y el texto de los ítems tiene tamaño 10 en lugar de 8.
Si estás desarrollando plug-ins que contribuyen menús y/u opciones de menú a la interfaz de usuario, probablemente te ha pasado como nos pasa a todos: nos volvemos locos buscando el ID del menú que tengo que utilizar para contribuir mi extensión de ese menú. Esto no es algo nuevo. La gente que desarrolla plug-ins no suele publicar los sus IDs. Ni siquiera si el plug-in está pensado para ser extendido. Considérese por ejemplo el caso de CDT. Conocer el ID del menú contextual de la vista de proyectos de CDT no es inmediato.
Desde Eclipse 3.4 existe la posibilidad, al menos, de utilizar el Plug-in Spy (Ctrl+Alt+F1), que proporciona bastante información sobre los elementos seleccionados en la interfaz de usuario, indicando los IDs si los hay, las clases a las que pertenecen las selecciones, la clase de la vista seleccionada, etc. Además indica también el plug-in donde se define la vista, por ejemplo. Conocer el plug-in es una ayuda inestimable cuando hay que buscar una clase o un paquete entre decenas de plug-ins (un número habitual si uno trabaja extendiendo JDT o CDT, por ejemplo).
David Carver ha publicado un post donde pide a los desarrolladores de Eclipse que por favor, ¡publiquen sus IDs! Ya que esta es una forma de favorecer también la adopción de tecnología Eclipse. Por lo visto esto ya lo empezaron a hacer la gente de WTP (Web Tools Project), el proyecto que da soporte al desarrollo Web en Eclipse. Y es que con este tipo de iniciativas nos beneficiamos todos.
Acaba de terminar el Eclipse Summit Europe 2009. Ian Skerret ha publicado un interesante resumen del perfil de los asistentes al congreso (al que nosotros no hemos ido, pero esperamos que sea la última vez).
En la pregunta 3, ¿cómo usas Eclipse?, nosotros habríamos marcado Research, Building internal apps on Eclipse y Education.
A la pregunta 4, ¿Cuál es tu perfil profesional?, si fuera de múltiple respuesta diríamos Academic researcher, Developer y Architect. Porque aquí lo mismo estás intentando recuperar algo de un disco duro que se te ha corrompido, como al día siguiente estás preparando la experimentación para tu siguiente artículo o estás mejorando esa librería que va a hacer tu vida mucho más fácil (si se terminara algún día).
¿Qué proyectos Eclipse usas? Parece que la gente está usando mucho Equinox y RCP. Destaca también el segundo puesto de EMF. Me sorprende un poco ya que yo no lo uso, aunque sé que toda la gente que está metida en el mundo de los DSLs anda por ahí (recuerdos de una tesis: openArchitectureWare, Montages, etc). En nuestro caso, andamos liados con JDT, CDT, RCP, BIRT, ECF.
Si vives en el mundo Eclipse, probablemente estés familiarizado con RCP y hayas realizado algún proyecto cuyo resultado haya sido un producto de este tipo. RCP son las siglas de Rich Client Platform y básicamente proporciona una plataforma sobre la que construir aplicaciones (de escritorio). Esta plataforma está constituida principalmente por Equinox (la implementación de OSGi en Eclipse).
Si además tu producto basado en RCP tiene ya algún tiempo, es más que seguro que lo habrás actualizado en alguna ocasión. Quizá has evolucionado un poco el código y has vuelto a generar la aplicación desde cero. Cuando este es el caso, uno echa en falta poder disponer de los mecanismos de actualización que proporciona Eclipse, esas magníficas opciones Check for Updates e Install new software del menú Help.
Pues no hay que lamentarse más, porque RCP permite reutilizar el mismo mecanismo de actualización que trae el entorno Eclipse en nuestros productos. Además, la reutilización es bastante flexible. Por ejemplo, podemos restringir el uso exclusivamente para actualizaciones, impidiendo instalar nueva funcionalidad. O bien, podemos permitir que el usuario instale nueva funcionalidad pero sólo desde los repositorios p2 que le proporcionemos nosotros.
En esta página del wiki del proyecto Equinox se describe cómo hacerlo. El tutorial está soportado por una serie de proyectos que implementan los diferentes enfoques y que se pueden obtener del cvs con un simple checkout:
:pserver:anonymous@dev.eclipse.org:/cvsroot/rt
Es muy interesante también la sección Headless Updating on Startup, donde se describe cómo buscar actualizaciones del producto al arrancar.
CodeUrjc 