java - settitle - OSGI-manejo de JAR de terceros requeridos por un paquete
jslider java (6)
Estoy comenzando con el desarrollo de OSGI y estoy luchando por comprender la mejor forma de manejar JAR dependientes.
es decir, si estoy creando un paquete, lo más probable es que necesitaré utilizar algunos JAR de terceros. Cuando creo mi paquete JAR para implementarlo en OSGI, obviamente estos archivos JAR de terceros no están incluidos y, por lo tanto, el paquete no se ejecutará.
Entiendo que una opción es convertir estos JAR en paquetes y también implementarlos en el contenedor OSGI. Sin embargo, si solo necesitan ser utilizados por el paquete, esto no parece ideal.
¿Cuál es la mejor solución para esto? ¿Pueden los archivos JAR insertarse dentro del paquete JAR y, de ser así, es un enfoque razonable?
¿Podemos usar OSGI para anular los archivos jar del cargador de clases bootstrap cargados durante el tiempo de ejecución, como si quisiéramos anular JAXP1.4.5 disponible con Java7 a JAXP1.6, existe la función -Dendorese para anular la API predeterminada a la API actualizada. ¿Podemos hacer esto con la ayuda de OSGI?
Aquí hay un ejemplo si está utilizando el complemento Maven Bundle .
Nota: Este complemento importa automáticamente los paquetes que necesitan sus dependencias. Esto puede o no ser un problema para ti. Afortunadamente, puede suprimir los paquetes que realmente no necesita importar (consulte a continuación).
<Import-Package>
<!-- this was imported by one of the dependencies; I don''t really need it -->
!org.apache.jackrabbit.test,
*
</Import-Package>
<Include-Resource>
lib/concurrent-1.3.4.jar,
lib/jackrabbit-core-2.6.5.jar,
lib/jackrabbit-spi-2.6.5.jar,
lib/jackrabbit-spi-commons-2.6.5.jar,
lib/lucene-core-3.6.0.jar,
lib/tika-core-1.3.jar
</Include-Resource>
<Bundle-ClassPath>
.,
concurrent-1.3.4.jar,
jackrabbit-core-2.6.5.jar,
jackrabbit-spi-2.6.5.jar,
jackrabbit-spi-commons-2.6.5.jar,
lucene-core-3.6.0.jar,
tika-core-1.3.jar
</Bundle-ClassPath>
Casi siempre empaco cada frasco por separado. OSGi en sí está diseñado para la modularización y usted toma todo el sistema ad absurdum al no hacer esto.
Si desea convertir JAR en paquetes, puede usar la herramienta BND escrita por Peter Kriens . Pero primero le sugiero que busque el paquete en el Repositorio de paquetes de Enterprise de SpringSource si aún no lo han hecho por usted.
Es posible incorporar dependencias que no sean OSGi en el paquete.
Una forma fácil de hacerlo es usar Maven para administrar sus dependencias y Maven Bundle Plugin para construir su paquete. Eche un vistazo a las instrucciones <Embed-Dependency> y <Embed-Transitive> del Maven Bundle Plugin que se describe en la sección Incorporación de dependencias de la página de documentación del plug-in.
Como señaló Roland, esta no es una solución ideal con respecto a las intenciones de OSGi, es decir, modularización y reutilización de módulos individuales. Sin embargo, podría ser una solución pragmática por el momento hasta que las dependencias de terceros puedan convertirse en paquetes OSGi.
Este hilo es un poco viejo, pero quería señalar una de las limitaciones de las dependencias incrustadas. Recuerde que las dependencias están en el nivel jar, pero cuando exporta paquetes, algunas pueden necesitar venir de las dependencias incrustadas. Si esto ocurre, terminará con clases duplicadas, una en línea en el paquete de nivel superior y otra en el contenedor incrustado. Por supuesto, puede alinear todo el jar incrustado, pero antes de que lo sepa, esto se propaga a través de toda su cadena de dependencia. Este es solo uno de los problemas a los que se refieren Roland y otros.
Puede incluir un jar de terceros dentro de su paquete agregando el jar de terceros al directorio raíz del archivo jar del paquete y luego agregar un encabezado de classpath del paquete al manifiesto del paquete, por ejemplo:
Bundle-ClassPath: .,my3rdparty.jar
Si desea colocar jar de terceros en el subdirectorio, especifique la ruta sin usar el encabezado ./ , por ej.
Bundle-ClassPath: .,lib/my3rdparty.jar # (not ./lib/my3rdparty.jar)