¿Cuál es el caso de uso previsto para Bundle-Classpath en paquetes OSGI?

osgi-bundle

Question

Estoy tratando de entender el caso de uso previsto para Bundle-Classpath en paquetes OSGI.

Aquí está mi entendimiento, por favor ayúdame a entender si esto es correcto.

Digamos que estoy trabajando en la creación de un paquete OSGI que se implementará en un ecosistema de otros paquetes. El paquete en el que estoy trabajando necesita algunos otros paquetes, pero no se cargan / exportan en este ecosistema y no tengo control sobre lo que el ecosistema exporta. En tal escenario, puedo poner estos paquetes dentro de algún directorio (digamos ''lib'') que se convierte en parte de mi paquete. Estos paquetes también deben ser referenciados desde Bundle-Classpath, para que puedan ser cargados.

• ¿Es este un caso de uso correcto para Bundle-Classpath?
• ¿Estos paquetes adicionales también se cargarán en el contenedor OSGI y los paquetes exportados por ellos estarán disponibles para otros paquetes?

Answer 1

Creo que puedes estar un poco fuera de aquí.

Una Bundle-Classpath es una lista ordenada, separada por comas, de las ubicaciones relativas de los archivos JAR de paquetes para buscar solicitudes de clase y recursos.

Lo que esto significa es que cuando alguna clase de paquete necesita otra clase en el mismo paquete, se busca la ruta completa de la clase de paquete del paquete que contiene para encontrar la clase.

De OSGI en Acción .

Consideremos un caso concreto. Imagine un paquete (archivo JAR) con la siguiente estructura:

src/a/A.class
src2/b/B.class
src3/c/C.class

si quisiera que aA , bB y cC estuvieran disponibles entre sí, tendría que definir src , src2 y src3 como pertenecientes a la src3 classpath del paquete. Eso significaría que tendría que agregar a su archivo de manifiesto la siguiente línea:

Bundle-ClassPath: src,src2,src3

Answer 2

El caso de uso más común para este encabezado es el empaquetado de bibliotecas externas. Digamos que tiene alguna biblioteca foo.jar y desea utilizar sus clases en su paquete.

Usted pone el frasco en su paquete como así,

/
com/company/Activator.class
foo.jar
META-INF/MANIFEST.MF

En tu manifiesto, ahora puedes usar

Bundle-ClassPath: foo.jar,.

Recuerda incluir el . en el classpath, o no podrá encontrar las clases en su paquete.

Cuando las clases están en Bundle-ClassPath , puede usarlas como cualquier otra clase: utilícelas en su código o expórtelos.

Answer 3

Bundle-ClassPath está diseñado para incluir dependencias en nuestro paquete, de modo que nuestro paquete se pueda implementar de forma independiente.

Tomemos un ejemplo. Supongamos que el código de mi paquete utiliza una biblioteca, por ejemplo, Google Guava. Tengo dos opciones para empaquetar mi paquete:

1. Simplemente crea mi paquete con solo mi propio código dentro de él. El paquete ahora tendrá las declaraciones de Import-Package que declaran una dependencia de Guava, y cualquiera que quiera implementar mi paquete en su aplicación también tendrá que implementar Guava.

2. Alternativamente, puedo incluir una copia de Guava dentro de mi paquete y hacer referencia a ella desde mi Bundle-ClassPath . Quienquiera que implemente mi paquete puede desplegar solo mi paquete, y no tiene que preocuparse por dónde obtener Guava. De hecho, la existencia de Guava dentro de mi paquete es un detalle de implementación, y el implementador ni siquiera necesita saber que lo estoy usando.

La elección entre estas dos opciones es una compensación. La opción 2 tiene la ventaja de que mi paquete es más fácil de implementar porque es independiente: todo lo que necesita está justo ahí. Por otro lado, mi paquete es mucho más grande de lo que debe ser, lo que podría convertirse en un problema si muchos otros paquetes también incrustan su propia copia de Guava.

Un problema más grave con la opción 2 es que todas las dependencias de la biblioteca ahora también se convierten en mis dependencias. En realidad, la guayaba es un ejemplo raro de una biblioteca de Java sin dependencias propias ... pero muchas otras bibliotecas de Java arrastran un enorme árbol de dependencias transitivas. Si utiliza este enfoque con, por ejemplo, Hibernate, su propio paquete también tendrá ese gran conjunto de dependencias. Esto se pone muy feo, muy rápido.

Por lo tanto, debe tener cuidado de no abusar de Bundle-ClassPath / Embed-Dependency . Solo debe considerar su uso si la dependencia es (a) pequeña y sin dependencias transitivas, y (b) su paquete usa la biblioteca como un detalle de implementación interna, es decir, no es parte de su API pública.

ACTUALIZAR

Olvidé contestar tu segunda pregunta sobre las exportaciones. La respuesta es NO, las exportaciones de cualquier "paquete" que coloque en su Bundle-ClassPath NO se convertirán en exportaciones de su propio paquete. De hecho, los archivos JAR que colocamos en Bundle-ClassPath no se tratan como paquetes, son solo archivos JAR.

Puede elegir exportar paquetes que provengan de los archivos JAR en su Bundle-ClassPath pero debe hacerlo en el MANIFEST.MF de su propio paquete.