osgi - felix - ¿Cuándo debo usar Import-Package y cuándo debo usar Require-Bundle?

osgi service

Question

OSGi permite determinar las dependencias a través de Import-Package , que solo conecta un paquete único (exportado desde cualquier paquete), y Require-Bundle , que se conecta a las exportaciones de un paquete específico.

En la creación de una aplicación OSGi greenfield, ¿qué enfoque debo usar para representar las dependencias? La mayoría de los paquetes serán internos, pero habrá algunas dependencias en los paquetes externos (de código abierto).

Answer 1

Creo que Require-Bundle es una cosa de Eclipse (que ahora se ha hecho en la especificación OSGi para acomodar Eclipse). La forma OSGi "pura" es usar Import-Package , ya que específicamente separa el paquete del paquete que lo proporciona. Debe declarar las dependencias de la funcionalidad que necesita (la API de Java proporcionada por una determinada versión de un paquete determinado) en lugar de de dónde proviene esa funcionalidad (lo que no debería importarle). Esto mantiene la composición de los paquetes más flexible.

Analogía de JavaScript: esto es como detectar si un navegador web admite una determinada API en lugar de deducir de qué cadena de usuario-agente dice qué tipo de navegador es.

Peter Kriens de OSGi Alliance tiene más que decir sobre esto en el blog OSGi .

Probablemente, el único caso en el que necesite usar Require-Bundle es si tiene paquetes divididos, es decir, un paquete que se distribuye en varios paquetes. Los paquetes divididos son, por supuesto, altamente desalentados.

Answer 2

Creo que Import-Package le da un acoplamiento más suelto y debería ser preferido. Lo uso cuando declaro dependencias en paquetes que no tengo, como slf4j, y puedo intercambiar las implementaciones que desee. Uso Require-Bundle cuando la dependencia es algo sobre lo que tengo control, como mis propios paquetes, porque cualquier cambio importante habría pasado por mi mismo de todos modos.

Answer 3

Evite el paquete de importación. Como los paquetes proporcionan relaciones de muchos a muchos entre paquetes, son propensos a ciclos de dependencia que son difíciles de detectar y evitar.

Require-Bundle, por otro lado, hace referencia a un solo paquete, lo que hace que el gráfico de dependencia se proteja de los ciclos mediante una verificación trivial de tiempo de construcción. Con Require-Bundle es mucho más fácil construir una arquitectura en capas con un nivel de abstracción inferior aislado.

Answer 4

Favorecer Importar-Paquete sobre Requerir-Paquete.

Require-Bundle:

• Especifica el paquete explícito (y la versión) a usar. Si un paquete requerido debe ser refactorizado y un paquete movido a otro lugar, entonces los dependientes necesitarán cambios en su MANIFEST.MF
• le da acceso a TODAS las exportaciones del paquete, independientemente de lo que sean y de si las necesita. Si las partes que no necesita tienen sus propias dependencias, las necesitará para
• los paquetes se pueden reexportar
• aunque no se recomienda, permite el uso de paquetes divididos, es decir: un paquete que se distribuye en varios paquetes
• se puede utilizar para dependencias sin código, por ejemplo: recursos, Ayuda, etc.

Paquete de importación:

• acoplamiento más flexible, solo se especifica el paquete (y la versión) y el tiempo de ejecución encuentra el paquete requerido
• Las implementaciones reales pueden ser intercambiadas
• Los paquetes dependientes se pueden mover a diferentes paquetes por el propietario del paquete
• Pero requiere que se mantengan más metadatos (es decir, cada nombre de paquete) a niveles más bajos de granularidad

Answer 5

No estoy convencido de que usar Import-Package sea mejor, porque mi expectativa predeterminada al trabajar con un paquete es trabajar con la API pública asociada. Por esa razón, Require-Bundle tiene más sentido.

Answer 6

Import-Package debería ser mejor porque, como se dijo anteriormente, puede mover un paquete de un paquete a otro sin cambiar el MANIFEST.MF del cliente existente

Pero...

Hay una razón práctica para usar Require-Bundle si está utilizando Eclipse para desarrollar sus paquetes:

Eclipse no utiliza paquetes como unidades de resolución. Utiliza los paquetes. Es decir, si usa un paquete de un paquete, Eclipse compila su paquete sin informar ningún problema con el uso del resto de paquetes no importados de ese paquete.

Podría (usted es humano) pensar que todo está bien y cargar su paquete para la implementación pero ... su paquete se romperá en el tiempo de ejecución.

Estoy seguro de ello porque este problema me ha sucedido (¡a mí!) Hoy.

La buena solución sería cambiar el contenedor de Eclipse classpath pero ... si esto no se va a hacer ... podría decidir evitar este tipo de problemas que requieren paquetes, en lugar de paquetes, pagando el precio mencionado (no compatible con versiones anteriores) movimiento de código entre paquetes).