La decepción llamada Eclipse BIRT

August 17, 2015

Desde hace bastantes años, y tras superar la curva de aprendizaje inicial, siempre he utilizado Vim como editor para todo. Me gusta porque, dentro de su crudeza, ofrece una potencia infinita sin despegar las manos del teclado; p.ej. no hay día en que no haga uso de las búsquedas y sustituciones con expresiones regulares.

Sin embargo, hace unos pocos meses empecé a preguntarme si estaba perdiéndome algo, si estaba quedándome atrás en el uso de las herramientas. Entre otras cosas, cavilaba sobre las ventajas que podía ofrecer Eclipse a los desarrolladores de aplicaciones. Yo seguía muy contento con mi Vim pero, ¿y si me estuviera quedando atrás?

Como parte del diseño arquitectónico de una nueva aplicación, tropecé con BIRT, acrónimo de Business Intelligence and Reporting Tools (algo así como “Inteligencia Comercial y Herramientas de Informes”), un proyecto open source de la Fundación Eclipse para generación de informes y visualización de datos. Buscaba un proyecto que pudiera adaptar a mis necesidades específicas; en concreto, mis informes eran realmente tickets/entradas para eventos, pero guardaban muchas similitudes con los informes convencionales: requerían elementos de visualización, diseños variados, se alimentaban de orígenes de datos, etc. Así que había encontrado lo que buscaba, o eso parecía.

Comencé por descargar la distribución todo-en-uno que incluye Eclipse con los plugins de BIRT y todas sus dependencias. De hecho, esta fue la única forma que tuve de hacerlo funcionar, pero no quiero adelantar acontecimientos. De inmediato comencé con el primer tutorial del sitio principal de BIRT. En poco tiempo, y habiendo sufrido tan solo un colapso repentino de Eclipse, pude completarlo: el informe se ejecutaba correctamente y podía visualizarlo en varios formatos: PDF, HTML, etc.

Lo siguiente que hice fue estudiar la arquitectura de BIRT para entender cómo podía sacarle partido, y entendí que está compuesto de los siguiente componentes principales:

  • Design Engine API (DE API): permite crear diseños, normalmente almacenados como ficheros .rtpdesign (con formato XML). Éstos definen las fuentes de las que obtienen los datos para mostrar en los informes. La API permite modificar el diseño al vuelo.
  • Report Engine API (RE API): ejecuta el informe con los datos obtenidos de las fuentes establecidas.
  • Chart Engine API (CE API): específico para gráficas y mapas.

También hay un componente de visualización, el Report Viewer, creado como aplicación Java EE que se puede incluir en cualquier proyecto Java EE.

Además, hay disponible una utilidad de diseño de informes llamada BIRT Report Designer, creada como RCP (Rich Client Platform) de Eclipse, que hace uso la DE API internamente. En este punto me encontré algo confuso: ¿qué era eso de Rich Client Platform? Desde luego, sonaba grandioso, ya que ofrecía portabilidad, facilidad de integración, reusabilidad, etc. En la wiki de Eclipse lo definen como “el conjunto mínimo de plug-ins necesarios para construir una aplicación de plataforma con interfaz gráfica”. ¿Se entiende? Yo no lo entendí.

Después de investigar unos cuantos días, llegué a una definición más comprensible para mí: partimos de que Eclipse es un entorno basado en componentes, denominados plug-ins en su argot. En 2003, los desarrolladores de Eclipse pensaron que era una buena idea permitir que otros desarrolladores utilizaran esos mismos componentes para crear otras aplicaciones, distintas del propio Eclipse. Para ello se basaron en la especificación OSGi de sistemas modulares, aunque la nomenclatura en el mundo Eclipse difiere, p.ej. los plug-ins de Eclipse se llaman bundles de OSGi.

Eclipse dispone del entorno PDE (Plugin Development Environment) para desarrollo de plugins. Un RCP existente se pueden importar en Eclipse para ejecutarse desde ahí o incluirse en un nuevo proyecto de plugin para extenderlo/reutilizarlo y, posteriormente, exportarlo como producto, de forma que pueda ejecutarse como una aplicación independiente.

En este punto, cualquier desarrollador que quiera utilizar el modelo de componentes de Eclipse se topará con vocabulario nuevo: product, product configuration, extensions, extension points, plugin manifest, etc. El modelo realmente es elegante, pero me sentí abrumado por tantos conceptos nuevos. No obstante, me propuse apalancarme con él, así que creé mi primera aplicación RCP usando el conjunto mínimo de plugins, que son dos: org.eclipse.ui y org.eclipse.core.runtime, ¡y funcionó!

Otra historia fue incluir todos los plugins de BIRT. Lo intenté de varias formas: descargando los fuentes del BIRT Report Designer RCP como un conjunto de plugins, descargando la version “All-in-one” ¡pero la RCP no estaba en esta versión! Así que probé a incluir los archivos de uno que faltaban en el otro.

Tanto si hacía mi propia combinación, como si no, acababa con discrepancias en las versiones de los plugins individuales y con dependencias no resueltas. Por supuesto, traté de resolver las dependencias manualmente, pero nada… Releí la documentación de Eclipse sobre desarrollo de plugins, pero continuamente me perdía porque nada parecía funcionar.

Conclusión

Toda la explicación de mis tentativas de usar BIRT para mi proyecto viene de dos semanas de intentos frustrados. Realmente, el desarrollo de plugins con Eclipse y, en general, el desarrollo con Eclipse, no es lo que esperaba y creo que no me he perdido nada por no haberlo usado antes.

Para mí, la gestión de dependencias de Eclipse deja mucho que desear, el desarrollo de plugins (basado en el modelo OSGi) es demasiado complicado y el IDE en sí mismo, altamente inestable. Mi experiencia en el desarrollo de plugins con Eclipse me ha aportado algunos de los momentos más frustrantes como desarrollador de software de toda mi vida.

Si no está satisfecho en el RCP Designer tal y como se entrega, mejor pruebe Pentaho Reporting (no recibo comisiones por publicidad).

Pentaho Reporting también es Java, y tiene un diseñador de informes que está disponible el GitHub de Pentaho Reporting. Viene con las herramientas apropiadas de construcción que un ingeniero espera: puede usar Maven o Ivy+Ant.

En el proceso de construcción de los artefactos todo funciona como cabe esperar. Con solo dos comandos, uno dispone de una aplicación Java que se ejecuta perfectamente. En cuestión de minutos, incluí mis propias modificaciones en el código fuente y construí la aplicación para ver mis modificaciones tener efecto. ¡Increíble!

Como colofón, le animo a abandonar BIRT y a darle una oportunidad a Pentaho. Malgasté dos semanas enteras con BIRT y Eclipse sin conseguir resultados en absoluto, mientras que en unas pocas horas pude encaminarme hacia mis objetivos con Pentaho. Y hay mucho más que el diseñador de informes en Pentaho.

Desde mis primeras pruebas han pasado algunos meses; ahora el diseñador de informes de Pentaho se adapta perfectamente a los requisitos iniciales, incluyendo multitud de modificaciones en el código fuente.

Espero que esto le pueda ahorrar un tiempo muy valioso.

Archivos