Flujo de trabajo de desarrollo de OSGi eficiente

Question

Trabajo en un producto compuesto por muchos paquetes que se ejecutan como funciones en la parte superior de karaf. Por lo general, nuestros desarrolladores trabajan en un paquete a la vez. Nuestro desarrollo normal es algo así como: codificar, compilar, copiar paquetes para desplegar carpetas, probar. También descubrimos que HotDeploy solo se rehúsa a anular ciertos paquetes que están instalados como características sin un reinicio del servidor o una función de desinstalación/reinstalación, por lo que a veces el ciclo es más largo.

Mi pregunta es: ¿alguien en la comunidad tiene una mejor manera? La forma en que hacemos las cosas funciona, pero siento que es bastante lenta e ineficiente, ¡y estoy apostando a que alguien ha logrado algo mejor!

EDIT: Me doy cuenta de que no estaba muy claro en mi pregunta ... Estamos utilizando Equinox debajo de Karaf. También usamos Eclipse y Maven, aunque no sé si usar Maven es relevante.

Answer 1

Suena como usted quiere el dev: reloj comando. De la documentación:

El comando del reloj se puede utilizar para ayudar en el momento del desarrollo. Le permite configurar un conjunto de URL que se supervisarán. La ubicación de todos los paquetes que coincida con la URL dada será automáticamente actualizada. Esto evita la necesidad de actualizar manualmente los paquetes o incluso copiar el paquete en la carpeta del sistema si es necesario. Tenga en cuenta que las URL única a base de Maven Maven e instantáneas en realidad se actualizarán de forma automática, por lo que si se ejecuta

dev: * reloj

Será realmente supervisar todos los paquetes que tienen un mvn ubicación coincidente: * que tienen '-SNAPSHOT 'en su url.

Al hacer "dev: watch --help" desde el shell de Karaf se mostrarán sus banderas y argumentos disponibles.

Algo similar es el PAX plugin

Cualquiera de estos funcionará bastante bien si tienes el plugin de Maven para Eclipse m2.

ACTUALIZADO: En mi empresa nos esforzamos por ser lo más TDD posible, por lo tanto, mucho se hace un desarrollo sin iniciar explícitamente Karaf. En la combinación normal de pruebas unitarias también usamos Pax Exam, que es en gran parte fantástico incluso cuando se ejecuta desde Eclipse =)

Esto ayuda a asegurarnos de que no estamos demasiado atados a los detalles de Karaf ya que se ejecuta con Equinox/Felix/Concierge (así que me burlo de varios detalles de Karaf de los que dependemos como la autenticación JAAS). Junto con muchas otras herramientas/funcionalidades geniales, es capaz de aprovisionar las características de Karaf y usar TinyBundles, incluso puede crear paquetes sobre la marcha (de nuevo, es útil para burlarse/trocear).

Pax Exam se conecta al JUnit framework al proporcionar JUnit @Runner, la última versión (2) es mucho más rápida y tiene API basada en DSL, por lo que las pruebas son bastante concisas y legibles.

El uso de Pax Exam nos da una buena cobertura de prueba y cortos tiempos de desarrollo. Donde las pruebas son menos prácticas o estamos buscando errores que no aparecen en las pruebas, el comando dev: watch es invaluable.

En resumen; IMO definitivamente debe conducir sus desarrollos con pruebas (Pax Exam se insertará en su construcción existente muy bien y una vez que se acostumbre a ella, encontrará el desarrollo más rápido). Puede comenzar a usar el dev: vea el comando inmediatamente, sin duda acelerará su situación actual.

ACTUALIZACIÓN 2: Al responder a otra pregunta agregué un ejemplo de Maven, Pax-Exam probando un ComponentFactory. Test Driven Development es sin duda el flujo de trabajo más eficiente disponible para los desarrolladores de hoy.enlace a la pregunta: osgi: Using ServiceFactories? y enlace al código fuente: http://dl.dropbox.com/u/2465717/net.earcam.example.servicecomponent_2011-08-16_15-52.tgz

Answer 2

He obtenido excelentes resultados utilizando Equinox en Eclipse, incluso la sustitución de códigos calientes funciona correctamente. concedida, la plataforma objetivo es pequeña y solo tenemos aproximadamente 50 paquetes propios, pero el flujo de trabajo es el siguiente:

Primero, tenemos una plataforma de destino que contiene todos los paquetes de terceros y Eclipse, Eclipse se encarga de descargar & administrándolas. Luego, el espacio de trabajo tiene todos los paquetes del proyecto, agrupados en 3-4 conjuntos de trabajo. La compilación ocurre como siempre en el guardado, a veces GWT necesita ser recompilado, pero aun así los cambios se recogen inmediatamente porque no es necesario que ocurra una implementación: el sistema Equinox en ejecución usa las carpetas de proyectos desempaquetados como paquetes. Ejecutar esto desde dentro de Eclipse nos permite reemplazar el código caliente, cambiar los archivos de la plantilla sobre la marcha, solo los cambios en MANIFEST.MF/plugin.xml deben actualizar el paquete, y aun así, generalmente es más rápido reiniciar el framework que escribir la consola.

Answer 3

Depende de la plataforma de Karaf: Felix o Equinox.

Equinox

Eclipse tiene excelente (o casi excelente) de apoyo para el lanzamiento de Equinox con paquetes de su elección. Las dos cosas que hay que preparar son:

1. paquetes, se están desarrollando, disponible en el espacio de trabajo como proyectos Plug-in
2. Plataforma de destino, que contienen los paquetes restantes de la aplicación

Tal configuración le permitirá realizar cambios fácilmente en sus paquetes, incluso el tiempo de ejecución y reiniciar fácilmente el tiempo de ejecución cuando sea necesario. Veo que Karaf es más adecuado cuando se desarrolla en un sistema remoto, donde los paquetes se implementan a través de SSH o FTP o cuando se utilizan herramientas de compilación externas como Maven, que tienen la capacidad de copiar automáticamente el paquete en el tiempo de ejecución una vez creado.

Si está utilizando Equinox, esto le dará una ventaja adicional ya que el tiempo de ejecución ejecutará el código directamente desde el área de trabajo.

Felix

Felix no parecen tener este tipo de apoyo para el lanzamiento de Eclipse (aunque hay un trabajo hacia este, seguido de this Jira issue). También puede iniciarlo como una aplicación Java normal, pero esto está lejos de ser conveniente. En este caso, usar Maven será una alternativa mucho mejor. Aún puede configurar Eclipse para aprovechar al máximo las otras funciones de PDE, solo el inicio se realizará de forma externa.

Resumen

En resumen, siempre se puede automatizar todo a través de Maven y Karaf será de gran ayuda en este sentido. Eclipse dará un poco de ventaja, si está utilizando Equinox. Debería poder reemplazar el hot-code independientemente del método que esté utilizando, porque el reemplazo del código de acceso directo ni siquiera considera OSGi (excepto en el único caso, cuando recarga su paquete y se crea un nuevo cargador de clases).)

Answer 4

si utiliza Eclipse Eclipse Libra puede ser útil para usted. Libra puede iniciar Felix, Equinox y Knopflerfish dentro de Eclipse como cualquier otro servidor con WST. Tienen algunos videos de youtube sobre cómo usarlo.

También escribió algunas herramientas que pueden ayudar:

• un paquete OSGi que recoge servicios OSGi que coinciden con el filtro (osgitest = junit4). Con eso no escribes clases Junit pero puedes proporcionar objetos preconfigurados (por ejemplo, con Blueprint OSGI). JUnit que se ejecuta en base a las anotaciones provistas en la interfaz que implementa su servicio.
• Un plugin Maven que tiene los siguientes objetivos útiles
  • iniciar una contenedores OSGI y desplegar el proyecto Maven paquete con todas sus dependencias (que son paquetes OSGi, por supuesto). El inicio del contenedor OSGI se realiza con la ayuda de PAX Exam pero las pruebas JUnit se inician con la ayuda del paquete OSGI que escribí (que ejecuta los servicios OSGI que puede proporcionar).
  • Crear una carpeta que contiene un acceso directo a todas las dependencias del proyecto (que se encuentra en el directorio de recompra experto o destino de la carpeta)

Si los proyectos se implementan en el servidor (Eclipse Libra) Tengo que decir solo actualizar X donde X es la identificación del paquete y todo se actualiza rápidamente. No es necesario volver a compilar los proyectos que se publican en el servidor si ejecuta Equinox en Libra ya que apunta a la carpeta de clases de destino que se actualiza tan pronto como guarde su clase o pom.xml.

Si no publica su proyecto en el servidor pero lo agrega como un paquete en el contenedor que apunta a la carpeta de acceso directo, también puede ejecutar el comando de actualización en la consola OSGi después de ejecutar mvn install (sin reiniciar el servidor)

Una guía paso a paso está disponible en http://cookbook.everit.org/

con el siguiente método anterior es posible escribir pruebas como pruebas de TDD y ejecutarlos como parte de un experto en compilar en el servidor de CI.

¡Espero que estas herramientas sean tan útiles como yo!