Administrar una aplicación OSGi grande

Question

Tengo una aplicación OSGi grande y en crecimiento con varios paquetes. Tengo curiosidad por saber la mejor manera de administrar este tipo de aplicación. Actualmente, estoy usando Eclipse y Maven, pero aunque esto es excelente para crear paquetes (a través de maven-bundle-plugin), hasta ahora no ha sido fácil administrar toda la aplicación.

Lo que me gustaría hacer es tener UNA configuración de ejecución o UN pom.xml que se pueda iniciar y se pueda construir y ejecutar toda la aplicación / proyecto. Además, me gustaría tener algo que sea bueno para la depuración.

He oído hablar de PAX Construct y lo tengo instalado en Eclipse, pero hasta ahora ha sido de poca ayuda (tal vez no lo estoy usando correctamente).

Estoy seguro de que hay personas con grandes aplicaciones OSGi que se administran correctamente. Cualquier consejo que se pueda compartir sería de gran ayuda.

Gracias Stephen

Answer 1

Una configuración de ejecución es posible a través de Pax Runner . Le permite elegir la implementación de la plataforma OSGi, especificar perfiles (conjuntos de paquetes preempaquetados para algún rol, por ejemplo, web , log , ds , etc. .) y tiene un buen soporte de aprovisionamiento, por ejemplo, puede cargar paquetes desde el repositorio de Maven. Como resultado, puede tener una configuración de ejecución como

--platform=felix
--log=INFO
--profiles=scalamodules,ds,config,log
mvn:com.my/bundle/1.0.1-SNAPSHOT@update
# other bundles

En caso de que su aplicación sea muy grande o tenga aplicaciones diferentes, también hay una manera de crear sus propios perfiles.

Answer 2

Bueno ...

Todo depende de lo que quieres decir con "gestionar" la aplicación.

Para el lanzamiento, la creación y la depuración del tiempo de desarrollo: Eclipse IDE debería ajustarse perfectamente a la factura.

Maven ... No puedo hablar por eso, ya que nunca lo he usado.

Tenemos una aplicación bastante grande basada en eclipse (varias, en realidad) y, por el lado del desarrollador, no estamos usando nada especial además del Eclipse y su SCM integrado.

En el servidor de compilación cc, también utilizamos eclipse sin cabeza para hacer la construcción y el empaquetado.

Ahora, la configuración del espacio de trabajo se ha ido un poco fuera de control últimamente con todas las dependencias y los pasos de compilación intermedios, por lo que estamos investigando Buckminster para gestionar la materialización de la plataforma objetivo y los recursos del espacio de trabajo.

Si eso funciona, probablemente también pasaremos a construir con Bucky, seguro que parece prometedor.

(No tengo ninguna experiencia con PAX, pero de un vistazo, también parece prometedor ...)

Answer 3

Soy bastante nuevo en OSGi pero,

¿no sería posible usar el servicio OBR de tal manera que tendrías un archivo de repositorio OBR que necesita los paquetes y dejar que el servicio OBR descubra las dependencias y complete su OSGIhost por usted?

Answer 4

Esta área creo que tiene muy poco apoyo en este momento. OSGI realmente no define nada acerca de la implementación o el empaquetado, por lo que depende de otros marcos (por ejemplo, Eclipse) crear su propia forma de hacerlo.

Si está creando una aplicación RCP (base Eclipse), los sistemas de eclipse hacen todo esto, hasta crear exes, etc. Sin embargo, las compilaciones se realizan principalmente en el espacio de trabajo de Eclipse, las compilaciones sin cabeza son más complicadas. El proyecto Tycho está tratando de hacer esto más sensible al unirse a los ciclos de compilación de Maven y Eclipse, sin embargo, todavía se centra en aplicaciones RCP en lugar de OSGI genérico.

Si no está haciendo RCP, que también es mi situación, entonces probablemente tenga que lanzar su propia solución, ya que no he encontrado ninguna solución general. Aquí hay un resumen de lo que hacemos:

Definimos un proyecto POM que enumera todos los paquetes contenidos en su aplicación. Todo lo que este proyecto hace es enumerar las referencias; llamémoslo el proyecto 'lista de paquetes'.

Luego, usamos la provisión de pax para ejecutar el proyecto en modo de desarrollo. Esto se logra haciendo que el pom de 'lista de paquetes' sea el padre del pom de aprovisionamiento del proyecto pax (generalmente en la carpeta 'provision'). Luego, cuando inicia pax, utiliza la lista de paquetes de ese proyecto para iniciar OSGI. Las referencias de paquete en el proyecto 'lista de paquetes' deben marcarse como alcance 'provisto' para que esto funcione.

Luego, para crear una distribución, tenemos otro proyecto. Este proyecto también tiene el proyecto 'bundle-list' como padre. Este proyecto utiliza varios complementos para crear una distribución, incluida la descarga de los frascos de paquetes. La distribución incluye scripts que inician OSGI, pero estos están escritos a mano, aquí no hay sistemas de pax.

Esto funciona bien para nosotros para mantener la lista de paquetes en un solo lugar, pero todavía hay muchas secuencias de comandos escritas a mano, y hay problemas para compartir la configuración entre los dos sistemas, por ejemplo archivos de configuración, niveles de inicio de paquete, etc.