Ejemplo OSGi en Eclipse

Como Eclipse está basado en Equinox (un contenedor OSGi) y además es mi IDE preferido, he comenzado a hacer mis primeros pinitos y quería compartir estos primeros pasos.

Run > Open Run Dialog > OSGi Framework > OSGi Framework
Pulsamos en “Duplicates the currently selected launch configuration”, renombramos “OSGi Framework (1)” a un nombre con el que nos encontremos más cómodos, p.ej. “OSGi Framework (Degesys)”

En la pestaña “Bundles” veremos dos grupos de bundles (todos seleccionados): Workspace y Target Platform. Deseleccionemos “Target Platform”.

File > New Project > Plug-in Project
Project Name: hellobundle
This plug-in is targeted to run with: an OSGi framework (yo he elegido “standard”)

Next , Next

Create a plug-in using one of the templates: Hello OSGi Bundle

Next , Finish

Seleccionamos la raiz de nuestro proyecto recién creado “hellobundle” y pulsamos “Alt+Shift+X, O” y seleccionamos nuestra configuración “OSGi Framework (Degesys)”. Se abrirá la consola y aparecerá un mensaje como el siguiente:

osgi> Hello World!!

Ponemos el cursor en la consola y escribimos “close”.

¡¡Ya hemos ejecutado nuestro primer bundle!!

PAX : OSGi made easy

Estas últimas semanas tengo bastante abandonado este blog porque estamos comenzando un proyecto muy bonito a la vez que difícil (al menos para mi): estamos valorando la posibilidad de desarrollar nuestro framework SOA basándolo en OSGi y SCA. Para ello, mi compañero Sixto está montando Newton con Spring:OSGi y todo el entorno de desarrollo que nos permita construir y desplegar nuestras aplicaciones en este nuevo entorno. Y en este orden de cosas, hemos visto que hay un par de herramientas muy nuevas que nos van a permitir acelerar muchas tareas: se trata de pax-runner y pax-construct.

Aquellos que tengáis algo que ver con OSGi, no perdáis ni un momento en echar un vistazo a este proyecto PAX (dentro de otro proyecto más genérico, OPS4J) porque merece la pena: puedes configurar tu entorno de ejecución y lanzar el contenedor de tu elección (por defecto es Apache Felix) con extrema facilidad (un fichero txt). Y muy similar es el proceso de construir una aplicación, incluso puedes “osgificar” un jar sin más que ejecutar pax-construct.

Este proyecto es un gran reto para mi, pero también por eso mismo está siendo tan apasionante.


Powered by ScribeFire.

Degesys se decide por Eclipse RCP

Después de algunas semanas evaluando diferentes opciones e incluso elaborando una PoC (prueba de concepto), en Degesys hemos llegado al convencimiento de que debemos desarrollar las interfaces de usuario para escritorio con Eclipse RCP.
Mis compañeros Pablo Navais y Sixto Cantolla han estado haciendo este trabajo, durante el cuál han evaluado fundamentalmente Eclipse RCP, NetBeans RCP, Spring RCP y Swing Application Framework (JSR-296) y en el estudio que han elaborado han concluído lo siguiente:
  • Eclipse RCP es el más maduro, estable, completo y bien documentado del mercado. Además, al estar basado en SWT (e.d. componentes nativos) tiene un mejor rendimiento. Permite incorporar componentes Swing sin problemas. Tiene una curva de aprendizaje elevada, pero una vez pasada la barrera es muy productivo.
  • NetBeans RCP no está mal, pero Eclipse RCP está mejor.
  • Spring RCP se basa en independizarse del método de renderizado (usa Swing de momento) pero está aún un poco “verde”. Además, no tiene mucha documentación y tiene algunos defectos bastante llamativos. De todos modos, siempre podremos integrar Spring y Eclipse RCP. :-)
  • Y el que está verde del todo es Swing Application Framework, que no está aún concluída la especificación y tardará además en madurar (igual que le ocurre a cualquier framework). Sin embargo, por lo que se ha podido intuir, es una opción que en el futuro está llamada a jugar fuerte.
  • JavaFX parece que tiene problemas de rendimiento de tal calibre que ni tan siquiera lo consideramos.

En breve comenzaremos a desarrollar nuestra primera aplicación de escritorio: una consola de administración para un servicio interno que ya tenemos desarrollado. No es algo muy ambicioso, pero es la mejor manera de aprender. Si trataramos de hacer una aplicación para un cliente directamente, lo más seguro es que nos pegáramos el batacazo del siglo… y no queremos eso… :-)