2008-08-26 14 views
11

Hemos incorporado un tiempo de ejecución OSGi (Equinox) en una aplicación cliente-servidor personalizada para facilitar el desarrollo de complementos y, hasta ahora, todo va muy bien. Hemos estado utilizando Eclipse para crear complementos debido al editor de manifiesto incorporado, la administración de dependencias y el asistente de exportación. El uso de Eclipse para compilaciones de administradores no es muy propicio para la integración continua a través de Hudson.¿Cómo puedo gestionar las dependencias de compilación OSGi?

Tenemos paquetes OSGi que dependen de otros paquetes OSGi. Realmente odiaría codificar la orden de compilación en una compilación de ANT personalizada. Hemos hecho esto es el pasado y es bastante horrible. ¿Hay alguna herramienta de compilación que pueda administrar FÁCILMENTE las dependencias OSGi, si no las resuelve automáticamente? ¿Hay algún ejemplo DECENTE de cómo hacerlo?

ACLARACIÓN:

El genera scripts de creación solamente se pueden utilizar a través de Eclipse. Requieren ejecutar manualmente piezas de Eclipse. También tenemos algunos objetivos estándar que la construcción de Eclipse no tendrá, y no quiero modificar el archivo generado ya que puedo regenerar (sé que puedo hacer incluye, pero quiero evitar el archivo gen de Eclipse todo juntos)

Aquí es mi diseño del proyecto:

/ 
-PluginA 
-PluginB 
-PluginC 
. 
. 
. 

En el uso de la PDE de Eclipse, cada plugin tiene un Manifiesto, pero sin build.xml como el PDE lo hace por mí. Es difícil automatizar un proceso guiado con Hudson. Me gustaría configurar mi propio build.xml para compilar cada uno, PERO hay dependencias y problemas de compilación. Estos problemas son impulsados ​​por los archivos Manifest (que describen las importaciones OSGi). Por ejemplo, PluginC depende de PluginB que depende de PluginA. Deben construirse en el orden correcto. Me doy cuenta de que puedo controlar manualmente el orden de compilación, estoy buscando una herramienta para ayudar a automatizar la administración de dependencias de orden de compilación.

+0

¿Por qué no funcionan los servicios declarativos? – drozzy

Respuesta

1

El cierre de algunas viejas preguntas ...

Nuestra configuración no era propicia para maven debido a la falta de conectividad de red y el tiempo. Sé que hay configuraciones de maven fuera de línea, pero fue demasiado dado el tiempo. Con suerte, podremos utilizar una configuración adecuada cuando tengamos tiempo para reorganizar el proceso de compilación.

La solución implicaba Ant, BND y algunas tareas personalizadas. Las diversas dependencias del paquete se gestionan manualmente. Ya estábamos usando Ant; BND y las tareas personalizadas lo unieron todo. Las tareas personalizadas solo se aseguraron de que nuestros proyectos bnd/eclipse estuvieran sincronizados.

2

Utilizamos Buckminster. Es un marco de construcción y ensamblaje que se ocupa de la resolución de dependencias, la obtención de varios repositorios, la construcción y el empaquetado del producto.

Es un proyecto de herramientas de Eclipse. Se integra bien con PDE.

Esto significa que todos los metadatos que usamos para construir el RCP son útiles para que Buckminster los resuelva y construya. Por ejemplo, feature.xml y el encabezado Require-Bundle en Manifest.MF, .product.

No tenemos ningún script de compilación en cada paquete ahora; ahora tenemos una compilación única por producto. Buckminster se ocupa de recorrer el gráfico de dependencia.

Nos llevó un poco de esfuerzo hacer funcionar nuestro sistema existente de control de crucero/hormiga, aunque ellos (el equipo de Buckminster) comenzaron a utilizar Hudson para alojar el proyecto. Creo que su configuración de compilación también está disponible para descargar.

Estamos muy impresionados con él, a pesar de su relativa infancia.

También buscamos en Pax-Construct pero no queríamos usar Maven.

Actualmente también estamos buscando en Spring DM testing framework para aumentar el esfuerzo de la unidad de prueba.

7

Maven2 todo el camino; tiene un plugin de Eclipse llamado m2eclipse para ayudar a administrarlo, resuelve exactamente el problema de dependencia y algo más. Tiene un free online book as documentation.

Mire específicamente multi-module projects para agrupar muchos componentes y hacer que Maven resuelva el orden de compilación y las dependencias.

También hay un chapter on the Eclipse integration.

y que es sólo Eclipse y Maven, junto presentamos lo mejor algunas cosas interesantes para OSGi:

Y, fundamentalmente, el modelo de módulo Maven encaja perfectamente con el modelo de paquete OSGi. Hemos estado creando y administrando múltiples productos con cientos de paquetes utilizando Maven durante más de 3 años y es genial.

0

¿Puede explicar dónde se produce el problema? Usted menciona las dependencias del paquete OSGi. ¿Esto es durante el tiempo de ejecución? ¿O durante el tiempo de compilación? En el primer caso, debe considerar los servicios declarativos (consulte la especificación OSGi).

0

Utilizamos Hudson combinado con PluginBuilder para construir nuestros paquetes/complementos OSGi basados ​​en Eclipse. Esto se basa en el proceso PDE estándar de Eclipse para crear complementos. Esto significa usar Eclipse como el compilador.

2

Secundaria Maven2. Observe los complementos de Tycho para compilar: utilizan el compilador JDT de Eclipse para implementar todas las reglas OSGi en tiempo de compilación, de la misma manera que lo hace Eclipse en tiempo de ejecución.

Alternativamente, los complementos de Apache Felix BND también parecen populares. Prefiero Tycho porque parece unir más estrechamente los entornos de desarrollo de Maven y Eclipse.

1

PDE Headless build. Está bien documentado por Eclipse. Si está creando complementos de Eclipse, y desea hacerlo a través de la línea de comandos, la compilación sin cabeza Eclipse PDE es EL camino a seguir.

0

Maven no requiere conectividad a Internet! Use el interruptor -o, por el amor de Dios.

Cuestiones relacionadas