OSGi y bibliotecas heredadas

Question

He estado investigando OSGi por un tiempo y me pregunto cuál es la mejor manera de lidiar con " legacy " bibliotecas (que se lanzan como JAR simples, no como paquetes OSGi).

¿Cuál crees que es la mejor manera de manejar esto? Modificar su archivo de manifiesto y agregar la información mínima específica del paquete, luego volver a empaquetarlos es lo que hago en este momento, pero de alguna manera me parece incorrecto. ¿Debo usar la gestión de dependencia manual para estos JAR (hago esto para aquellas bibliotecas que tienen una alta probabilidad de ser utilizadas solo en una cierta parte de mi aplicación)?

En la medida en que estén disponibles, estoy usando paquetes para Eclipse (dado que estoy usando Equinox como plataforma OSGi, esto funciona bien para aquellas bibliotecas que están disponibles como paquetes).

¿Hay algún repositorio de paquetes además de los paquetes de Eclipse que debería conocer?

Answer 1

Spring se está volviendo OSGi a lo grande, usando Equinox como la plataforma subyacente.

http://www.springsource.org/dmserver

el blog de Rob Harrop vale la pena seguir si te gustan los desarrollos de OSGi.

Y para responder a su pregunta, aquí está el repositorio de paquetes OSGi de Spring:

http://www.springsource.com/repository/app/

Answer 2

También hay Eclipse Orbit que tiene varios paquetes preempaquetados para los usos de Eclipse. Y en lugar de modificar el manifiesto del paquete directamente, puede crear un paquete de envoltura que proporcione el Manifiesto usted mismo e incluir el Jar tal como está con un encabezado Bundle-ClassPath: foo.jar. Es un poco menos eficiente hacerlo de esta manera, ya que en tiempo de ejecución, foo.jar se extrae (al menos, en Equinox), pero podría ser más fácil para usted administrar el proceso de compilación con eso.

El repositorio Spring también es una buena fuente de bibliotecas de código abierto que han sido OSGi'ified.